Re: Comments regarding scala-pickling_0.10.1-1_amd64.changes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Comments regarding scala-pickling_0.10.1-1_amd64.changes

Andreas Tille-5
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.

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 <[hidden email]> 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.

> 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 :
> 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.

Thanks for your contribution

      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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Comments regarding scala-pickling_0.10.1-1_amd64.changes

Frédéric Bonnard
Hi,

On Tue, 11 Apr 2017 16:21:05 +0200, Andreas Tille <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Comments regarding scala-pickling_0.10.1-1_amd64.changes

Andreas Tille-2
Hi Frederic,

On Wed, Apr 12, 2017 at 10:14:20AM +0200, Frederic Bonnard wrote:
> > 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.

:-)
 

> > 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 ?

Well, may be we discussed this previously and I simply forgot.  Please
keep in mind that I'm doing lots of stuff and might forget something we
agreed upon before.  Feel free to remind me about this. ;-)

> (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.

OK, fine.

> 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 ?

Well, just tell me the sequence and the *.dsc file I should have a
sponsoring look.  I do not mind about RFS bugs as I said before.
 

> > 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

At least the last item is no reason.  Uploads to experimental are just
for those packages that are in testing right now and might need a bug
fix upload via unstable which should pass easily without any version
bump.

> 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.

Thanks again for the detailed explanation.
 
> > 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

So, well, just give me a sensible sequence for sponsoring and a pointer
to the according *.dsc files on mentors to enable me to dget it right
from your mail.

I'll try my best to help you through the bootstrap process.

Kind regards

    Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Comments regarding scala-pickling_0.10.1-1_amd64.changes

Frédéric Bonnard
Hi Andreas,

On Thu, 13 Apr 2017 20:24:53 +0200, Andreas Tille <[hidden email]> wrote:

> Hi Frederic,
>
> On Wed, Apr 12, 2017 at 10:14:20AM +0200, Frederic Bonnard wrote:
> > > 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.
>
> :-)
>
> > > 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 ?
>
> Well, may be we discussed this previously and I simply forgot.  Please
> keep in mind that I'm doing lots of stuff and might forget something we
> agreed upon before.  Feel free to remind me about this. ;-)
I understand that.

> > (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.
>
> OK, fine.
>
> > 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 ?
>
> Well, just tell me the sequence and the *.dsc file I should have a
> sponsoring look.  I do not mind about RFS bugs as I said before.
>
> > > 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
>
> At least the last item is no reason.  Uploads to experimental are just
> for those packages that are in testing right now and might need a bug
> fix upload via unstable which should pass easily without any version
> bump.
oh ok, thanks.
scala-pickling was accepted by ftpmasters in experimental.
Let's stick to experimental for these other packages for now, and
we'll work on pilon there too. Once we manage to get pilon package
working there, that will be a first good step and we can move everything
to unstable then. That's a proposal, let me know :)

> > 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.
>
> Thanks again for the detailed explanation.
>
> > > 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
>
> So, well, just give me a sensible sequence for sponsoring and a pointer
> to the according *.dsc files on mentors to enable me to dget it right
> from your mail.
Here is the list of dsc :
sbt :                    https://mentors.debian.net/debian/pool/main/s/sbt/sbt_0.13.13-1.dsc
sbt-template-resolver :  https://mentors.debian.net/debian/pool/main/s/sbt-template-resolver/sbt-template-resolver_0.1-1.dsc
sbt-launcher-interface : https://mentors.debian.net/debian/pool/main/s/sbt-launcher-interface/sbt-launcher-interface_1.0.0-1.dsc
scopt :                  https://mentors.debian.net/debian/pool/main/s/scopt/scopt_3.5.0-1.dsc
sbt-serialization :      https://mentors.debian.net/debian/pool/main/s/sbt-serialization/sbt-serialization_0.1.2-1.dsc
jawn :                   https://mentors.debian.net/debian/pool/main/j/jawn/jawn_0.10.4-1.dsc
json4s :                 https://mentors.debian.net/debian/pool/main/j/json4s/json4s_3.5.0-1.dsc
scala-tools-sbinary :    https://mentors.debian.net/debian/pool/main/s/scala-tools-sbinary/scala-tools-sbinary_0.4.2+2.11.M5-1.dsc
sbt-test-interface :     https://mentors.debian.net/debian/pool/main/s/sbt-test-interface/sbt-test-interface_1.0-1.dsc
sbt-ivy :                https://mentors.debian.net/debian/pool/main/s/sbt-ivy/sbt-ivy_2.4.0~rc1+dfsg-1.dsc

Let me know if you need other things for sponsoring.

> I'll try my best to help you through the bootstrap process.

Thanks again,

F.

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Comments regarding scala-pickling_0.10.1-1_amd64.changes

Andreas Tille-2
Hi Frederic,

On Fri, Apr 14, 2017 at 03:46:34PM +0200, Frederic Bonnard wrote:
> > Well, may be we discussed this previously and I simply forgot.  Please
> > keep in mind that I'm doing lots of stuff and might forget something we
> > agreed upon before.  Feel free to remind me about this. ;-)
>
> I understand that.

:-)
 

> > At least the last item is no reason.  Uploads to experimental are just
> > for those packages that are in testing right now and might need a bug
> > fix upload via unstable which should pass easily without any version
> > bump.
>
> oh ok, thanks.
> scala-pickling was accepted by ftpmasters in experimental.
> Let's stick to experimental for these other packages for now, and
> we'll work on pilon there too. Once we manage to get pilon package
> working there, that will be a first good step and we can move everything
> to unstable then. That's a proposal, let me know :)

Yes, that's fine for me.
 
> > to the according *.dsc files on mentors to enable me to dget it right
> > from your mail.
>
> Here is the list of dsc :
> sbt :                    https://mentors.debian.net/debian/pool/main/s/sbt/sbt_0.13.13-1.dsc
> sbt-template-resolver :  https://mentors.debian.net/debian/pool/main/s/sbt-template-resolver/sbt-template-resolver_0.1-1.dsc
> sbt-launcher-interface : https://mentors.debian.net/debian/pool/main/s/sbt-launcher-interface/sbt-launcher-interface_1.0.0-1.dsc

I spotted a missing
   Build-Depends: git
here and added it.  Make sure you add this in your source (or dget
whatever might be accepted)

> scopt :                  https://mentors.debian.net/debian/pool/main/s/scopt/scopt_3.5.0-1.dsc

Same here: Missing git in Build-Depends.

> sbt-serialization :      https://mentors.debian.net/debian/pool/main/s/sbt-serialization/sbt-serialization_0.1.2-1.dsc

Same here: Missing git in Build-Depends.

> jawn :                   https://mentors.debian.net/debian/pool/main/j/jawn/jawn_0.10.4-1.dsc
> json4s :                 https://mentors.debian.net/debian/pool/main/j/json4s/json4s_3.5.0-1.dsc
> scala-tools-sbinary :    https://mentors.debian.net/debian/pool/main/s/scala-tools-sbinary/scala-tools-sbinary_0.4.2+2.11.M5-1.dsc
> sbt-test-interface :     https://mentors.debian.net/debian/pool/main/s/sbt-test-interface/sbt-test-interface_1.0-1.dsc
> sbt-ivy :                https://mentors.debian.net/debian/pool/main/s/sbt-ivy/sbt-ivy_2.4.0~rc1+dfsg-1.dsc
>
> Let me know if you need other things for sponsoring.

I've sponsored all packages after changing the three above.
 
> > I'll try my best to help you through the bootstrap process.
>
> Thanks again,

You are welcome.  Lets hide these packages as Easter eggs for ftpmaster
inside the new queue. :-)

Kind regards

          Andreas.

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

sbt packages ongoing upload process

Frédéric Bonnard
> > Here is the list of dsc :
> > sbt :                    https://mentors.debian.net/debian/pool/main/s/sbt/sbt_0.13.13-1.dsc
> > sbt-template-resolver :  https://mentors.debian.net/debian/pool/main/s/sbt-template-resolver/sbt-template-resolver_0.1-1.dsc
> > sbt-launcher-interface : https://mentors.debian.net/debian/pool/main/s/sbt-launcher-interface/sbt-launcher-interface_1.0.0-1.dsc
>
> I spotted a missing
>    Build-Depends: git
> here and added it.  Make sure you add this in your source (or dget
> whatever might be accepted)

Ok, I'll pull everything from experimental.

> > scopt :                  https://mentors.debian.net/debian/pool/main/s/scopt/scopt_3.5.0-1.dsc
>
> Same here: Missing git in Build-Depends.
>
> > sbt-serialization :      https://mentors.debian.net/debian/pool/main/s/sbt-serialization/sbt-serialization_0.1.2-1.dsc
>
> Same here: Missing git in Build-Depends.

Good catch, thanks for those 3 !

> > jawn :                   https://mentors.debian.net/debian/pool/main/j/jawn/jawn_0.10.4-1.dsc
> > json4s :                 https://mentors.debian.net/debian/pool/main/j/json4s/json4s_3.5.0-1.dsc
> > scala-tools-sbinary :    https://mentors.debian.net/debian/pool/main/s/scala-tools-sbinary/scala-tools-sbinary_0.4.2+2.11.M5-1.dsc
> > sbt-test-interface :     https://mentors.debian.net/debian/pool/main/s/sbt-test-interface/sbt-test-interface_1.0-1.dsc
> > sbt-ivy :                https://mentors.debian.net/debian/pool/main/s/sbt-ivy/sbt-ivy_2.4.0~rc1+dfsg-1.dsc
> >
> > Let me know if you need other things for sponsoring.
>
> I've sponsored all packages after changing the three above.
>
> > > I'll try my best to help you through the bootstrap process.
> >
> > Thanks again,
>
> You are welcome.  Lets hide these packages as Easter eggs for ftpmaster
> inside the new queue. :-)
Looks like Easter was good for package acceptance as only 4 packages
still remain as pending uploads.
Let's wait for those and then we'll be able to start with pilon .
Regards,

F.

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: sbt packages ongoing upload process

Andreas Tille-5
On Tue, Apr 18, 2017 at 06:05:55PM +0200, Frederic Bonnard wrote:
> > Same here: Missing git in Build-Depends.
>
> Good catch, thanks for those 3 !

You are welcome. :-)
 
> > You are welcome.  Lets hide these packages as Easter eggs for ftpmaster
> > inside the new queue. :-)
>
> Looks like Easter was good for package acceptance as only 4 packages
> still remain as pending uploads.

I think new queue was close to empty even before Easter and thus
processing some of the new ones was easy.

> Let's wait for those and then we'll be able to start with pilon .

Perfectly fine

      Andreas.


--
http://fam-tille.de

Loading...