Re: request for reviews/sponsorship

[Andreas Tille]

Hi Sebastian,

since you did not got any answer for your mail that definitely deserves
it, I'll step in here.

On Wed, Jan 31, 2018 at 12:28:39PM -0700, Sebastian Kuzminsky wrote:
> Hello Debian Scientists, I'm an aspiring maintainer looking for feedback on
> a package I've made.  I hope that debian-science is a reasonable place to
> ask for this favor (I'm also asking on debian-mentors).
> 
> I'm interested in personal fabrication technologies, and to that end I've
> packaged dxf2gcode, a CAM program that takes 2d drawings of parts and
> produces g-code for running on CNC mills and lathes.  (This software is a
> bit like a slicer for 3d printing, but targets subtractive fabrication
> techniques instead of additive.)
> 
> Here is my ITP:  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888298
> 
> Here is my package on mentors.d.n:
> https://mentors.debian.net/package/dxf2gcode
> 
> And here is my RFS (which I should have used the mentors.d.n RFS template
> for, but didn't): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888526

I confirm that you have choosen the correct procedure to ask for
sponsoring by using mentors.d.n and ask on a potentially interested
mailing list.

I have some additional constraints which I have basically set to safe
myself from taking up to many sponsorships.  One constraint is that I
only sponsor from some team Git repository (for instance from Debian
Science[1]).  Another constraint is that the package needs to fit into
some Blend.  That's why I have set a "Sponsering of Blends" Wiki page[2]
where you get more detailed information about Blends and the "rules" of
SoB.  So you somehow need to find a task your package might fit into
be it either in the Debian Science Blend[3] or what might also fit the
3dprinter Blend[4].

Just respond to this mail on list in case you need more information
about Blends.

Kind regards

   Andreas.

[1] https://salsa.debian.org/science-team
[2] https://wiki.debian.org/DebianPureBlends/SoB
[3] https://blends.debian.org/science/tasks/
[4] https://blends.debian.org/3dprinter/tasks/

-- 
http://fam-tille.de

Re: mpi-defaults: Incorrect debian/1.9 tag

[Alastair McKinstry]

On 05/02/2018 16:18, Mattia Rizzolo wrote:
> On Mon, Feb 05, 2018 at 12:48:31PM +, Alastair McKinstry wrote:
>> I think we also need to change powerpc and ppc64 to mpich, as of openmpi3:
> Remember that switching a default mpi requires a library transition, and
> an ordered rebuild of all rdeps.
>
> I've added a README.source with such info.

True, and thanks.

I've just finished a rebuild of all rdeps against openmpi 3.0.1rc2, and
it looks good; just one small patch needed for python-escript (assumes
version numbers are always digits), nwchem FTBFS.

It looks like openmpi 3.0.1 will be out in a few days. Will test it,
then ask for transition permission.

regards
Alastair

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
 believing the innocent had everything to fear, mostly from the guilty but in 
the longer term
 even more from those who say things like “The innocent have nothing to fear.”
 - T. Pratchett, Snuff

Re: Project creation in science-team (Was: Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories))

[Andreas Tille]

Hi Philip,

On Mon, Feb 05, 2018 at 11:54:18AM +0100, Philip Rinn wrote:
> > 
> > Could you please move to science-team first to make me evaluate the final
> > status of the package?
> 
> Done: https://salsa.debian.org/science-team/node-pinkyswear
> 
> [The remarks for debian/control hold here as well. But I'd prefer to not 
> change it
> for this package as I still hope to get it under the javascript umbrella 
> sometime.]

That's a perfectly valid reason to leave control as is.  May be it makes
some sense to suggest javascript team to use cme in the future anyway.
 
> > Both things are no reason to stop me from sponsoring.  So if you confirm
> > that my last commit is fine for you I'll upload as it is now - otherwise
> > I'll upload your latest commit.
> 
> For me it's OK. I tried to stick to the Node.js packaging template to make it
> easier for Noe.js people to review it. As this package will stay in 
> science-team
> anyway I think using the cme file layout is fine.

Both are uploaded now.

Thanks for your work

   Andreas. 

-- 
http://fam-tille.de

Re: mpi-defaults: Incorrect debian/1.9 tag

[James Clarke]

On 5 Feb 2018, at 12:48, Alastair McKinstry  wrote:
> On 05/02/2018 12:42, James Clarke wrote:
>> Hi,
>> I've just done a team upload of mpi-defaults to add ia64 support, and did a 
>> bit
>> of cleanup at the same time (optional->extra, compat and standards version,
>> Vcs-*, etc). I noticed however that the debian/1.9 tag currently points to 
>> the
>> debian/1.8 commit, as opposed to 5941a2422bdb7ae0f53dd97ef1d451f19b5a391a. 
>> I've
>> re-created the tag on Alioth to point to the right commit in case anyone 
>> clones
>> (or fetches) via SSH, but GitLab doesn't let non-Masters delete tags, so I
>> can't fix it on Salsa. Could someone please delete the tag on Salsa for me?
>> 
>> James
>> 
>> NB: If you have a local checkout with the debian/1.9 tag, git (deliberately)
>> doesn't update local tags, so you'll need to delete it and re-fetch it 
>> once
>> this has been fixed if you want to have the correct one.
>> 
>> 
> 
> Hi,
> 
> Deleted the 1.9 tag on salsa.

Thanks, new tag pushed.

> I think we also need to change powerpc and ppc64 to mpich, as of openmpi3:
> "
> configure: error: Big endian PPC is no longer supported.
> "

Ah yes, I remember seeing the upstream commit where they decided to remove the
code rather than not have it officially supported. I don't understand why they
have to remove something like that when things like hppa and ia64 still work,
but alas. I'll let someone with more MPI knowledge deal with that when the 2->3
transition occurs.

Having said that, I *believe* if you alter the configure script to treat
big-endian powerpc like little-endian powerpc it will build fine, but they may
have since deleted other required bits. I wonder if we can convince upstream to
leave it in as an unofficial thing... :(

James

Re: mpi-defaults: Incorrect debian/1.9 tag

[Alastair McKinstry]

Hi,

Deleted the 1.9 tag on salsa.

I think we also need to change powerpc and ppc64 to mpich, as of openmpi3:
"

configure: error: Big endian PPC is no longer supported.
"

regards
Alastair

On 05/02/2018 12:42, James Clarke wrote:
> Hi,
> I've just done a team upload of mpi-defaults to add ia64 support, and did a 
> bit
> of cleanup at the same time (optional->extra, compat and standards version,
> Vcs-*, etc). I noticed however that the debian/1.9 tag currently points to the
> debian/1.8 commit, as opposed to 5941a2422bdb7ae0f53dd97ef1d451f19b5a391a. 
> I've
> re-created the tag on Alioth to point to the right commit in case anyone 
> clones
> (or fetches) via SSH, but GitLab doesn't let non-Masters delete tags, so I
> can't fix it on Salsa. Could someone please delete the tag on Salsa for me?
>
> James
>
> NB: If you have a local checkout with the debian/1.9 tag, git (deliberately)
> doesn't update local tags, so you'll need to delete it and re-fetch it 
> once
> this has been fixed if you want to have the correct one.
>
-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
 believing the innocent had everything to fear, mostly from the guilty but in 
the longer term
 even more from those who say things like “The innocent have nothing to fear.”
 - T. Pratchett, Snuff

mpi-defaults: Incorrect debian/1.9 tag

[James Clarke]

Hi,
I've just done a team upload of mpi-defaults to add ia64 support, and did a bit
of cleanup at the same time (optional->extra, compat and standards version,
Vcs-*, etc). I noticed however that the debian/1.9 tag currently points to the
debian/1.8 commit, as opposed to 5941a2422bdb7ae0f53dd97ef1d451f19b5a391a. I've
re-created the tag on Alioth to point to the right commit in case anyone clones
(or fetches) via SSH, but GitLab doesn't let non-Masters delete tags, so I
can't fix it on Salsa. Could someone please delete the tag on Salsa for me?

James

NB: If you have a local checkout with the debian/1.9 tag, git (deliberately)
doesn't update local tags, so you'll need to delete it and re-fetch it once
this has been fixed if you want to have the correct one.

Re: Project creation in science-team (Was: Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories))

[Philip Rinn]

Hi Andreas,

On 05.02.2018 at 11:43, Andreas Tille wrote:
>> The packaging is here (I'd like to move it to .../science-team/... before 
>> uploading)
>>
>> https://salsa.debian.org/rinni-guest/node-pinkyswear
> 
> Could you please move to science-team first to make me evaluate the final
> status of the package?

Done: https://salsa.debian.org/science-team/node-pinkyswear

[The remarks for debian/control hold here as well. But I'd prefer to not change 
it
for this package as I still hope to get it under the javascript umbrella 
sometime.]

>> And here it the packaging of node-shiny-server-client which should be in
>> science-team anyway
>>
>> https://salsa.debian.org/science-team/node-shiny-server-client
> 
> I've requested a release tag on Github[1].  This would help to create a
> sensible watch file.

Ah, that's a good idea!

> Moreover some cosmetic remark:  I'm very used to the cme file layout of
> debian/control.  You get it when using
> 
> cme fix dpkg-control
> 
> ... at least under normal conditions.  Cme is not yet adapted to salsa
> so it does not yet work with the current control file.  I hacked around
> this and commited the result.  I do not insist in this form but in teams
> with lots of contributors its nice to have some common layout to let
> the packages look somehow "familiar" for sponsors.  If you have strong
> esthetic reasons to insist on your old formatting feel free to revert
> my last commit.
> 
> Both things are no reason to stop me from sponsoring.  So if you confirm
> that my last commit is fine for you I'll upload as it is now - otherwise
> I'll upload your latest commit.

For me it's OK. I tried to stick to the Node.js packaging template to make it
easier for Noe.js people to review it. As this package will stay in science-team
anyway I think using the cme file layout is fine.


Thanks for the review!

Philip

Re: Project creation in science-team (Was: Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories))

[Andreas Tille]

Hi Philip,

On Mon, Feb 05, 2018 at 10:59:49AM +0100, Philip Rinn wrote:
> On 15.01.2018 at 13:32, Andreas Tille wrote:
> > Since you intended to package more of this I've just granted you master 
> > privileges.
> 
> thanks!

You are welcome.
 
> > I'll care for quick sponsoring.
> 
> I tried to find a sponsor for node-pinkyswear on the javascript list but 
> didn't
> succeed ... so to get things going it might be good to just keep it in the 
> Debian
> Science team for now. What do you think?

That's fine and not unusual.
 
> The packaging is here (I'd like to move it to .../science-team/... before 
> uploading)
> 
> https://salsa.debian.org/rinni-guest/node-pinkyswear

Could you please move to science-team first to make me evaluate the final
status of the package?
 
> And here it the packaging of node-shiny-server-client which should be in
> science-team anyway
> 
> https://salsa.debian.org/science-team/node-shiny-server-client

I've requested a release tag on Github[1].  This would help to create a
sensible watch file.

Moreover some cosmetic remark:  I'm very used to the cme file layout of
debian/control.  You get it when using

cme fix dpkg-control

... at least under normal conditions.  Cme is not yet adapted to salsa
so it does not yet work with the current control file.  I hacked around
this and commited the result.  I do not insist in this form but in teams
with lots of contributors its nice to have some common layout to let
the packages look somehow "familiar" for sponsors.  If you have strong
esthetic reasons to insist on your old formatting feel free to revert
my last commit.

Both things are no reason to stop me from sponsoring.  So if you confirm
that my last commit is fine for you I'll upload as it is now - otherwise
I'll upload your latest commit.

> Could you please review the packages and upload them if everything is fine?

Thanks for your work on this

   Andreas.

[1] https://github.com/rstudio/shiny-server-client/issues/12 

-- 
http://fam-tille.de

RFS: python-line-profiler/2.1-1

[Ghislain Vaillant]

Hi team,

Could someone please sponsor the following update to src:python-line-
profiler [1]? Just a boring update to the latest upstream release and
some housekeeping. It builds and tests fine with debomatic [2].

[1] https://salsa.debian.org/science-team/python-line-profiler 
[2] 
http://debomatic-amd64.debian.net/distribution#unstable/python-line-profiler/2.1-1/

Cheers,
Ghis