Re: [RFS] libsecrecy 0.0.2+dfsg-1

[Étienne Mollier]

Hi Andreas,

Andreas Tille, on 2020-11-14 19:28:48 +0100:
> On Sat, Nov 14, 2020 at 03:58:39PM +0100, Étienne Mollier wrote:
> > > I've seen your pushes.  Seems you did not found itp_from_debian_dir[1]
> > > which makes the ITP bug more convenient.  But its fine to do that
> > > manually.
> > 
> > > [1] 
> > > https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/scripts/itp_from_debian_dir
> > 
> > So that's where it keeps hiding from me!  :D
> 
> Sorry, I admit its nearly perfectly hidden (and I had to seek myself the
> repository - its in the PATH on my machines :-( ).  Any idea where to
> make it better visible is welcome.

Naive me headed toward the helper-scripts/ directory while
reading^W skimming through the MoM document, since this is where
the script to inject the code into Salsa was in the first place.
Maybe other applicants would do the same; if so, then I guess it
would be the appropriate place.  Just a thought, as that would
duplicate the code from dh-r scripts...

[...]
> > > Just let me know if its ready for sponsering (or may be I need to
> > > read on my mails ... ;-) )
> > 
> > No worries, I wanted to reread a thing or two today.  I think
> > that the package is suitable for review; I would be especially
> > happy of a triple check on the copyrights side:
> > 
> > https://salsa.debian.org/med-team/libsecrecy
> 
> Copyright looks good to me.  I tried to make the header only package
> "Architecture: all" but lintian shouted at me due to the pkg-config
> file in /usr/lib/TRIPLET - so I reverted that change.

Yes, I have been hoping to get it Architecture: all initially,
but I'm not sure if .pc should be architecture independent at
all.

(Out of curiosity, I had a look at build results, and I believe
it should work on kfreebsd 12.0, since getrandom(2) has been
implemented starting from this version, but we're still at 10.3
for the moment.  GPGME does not support GNU Hurd on the other
hand.)

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.


signature.asc
Description: PGP signature

[RFS] gsort and dependencies (Was: /usr/bin/picard Re: bcbio will need another while - needs gatk)

[Nilesh Patra]

Hi,

I packaged gsort and the rest of the dependency chain as needed by bcbio.
Everything seems to build+pass its autopkgtests.

The dependency chain is as follows:

1. golang-github-alexflint-go-scalar [1]
2. golang-github-alexflint-go-arg [2](depends on [1])
3. ggd-utils [3]   (depends on [2])
4. gsort [4]   (depends on [3] and [2])

Please consider to review + upload to NEW

PS:
Simple gbp-buildpackage will not work on [1] since this follows new
go-style guideline which drops pristine-tar[5]
Hence the way here would be to run origtargz and run pdebuild w/o gbp
You probably knew about this, but I re-iterated just in case you're not
used to the new workflow for go-team and this saves your time while
building this.
Please consider my best of intentions here.

[1]:
https://salsa.debian.org/go-team/packages/golang-github-alexflint-go-scalar
[2]:
https://salsa.debian.org/go-team/packages/golang-github-alexflint-go-arg
[3]: https://salsa.debian.org/med-team/ggd-utils
[4]: https://salsa.debian.org/med-team/gsort/
[5]:
https://go-team.pages.debian.net/workflow-changes.html#wf-2017-11-pristine-tar

Nilesh

Re: [RFS] gsort and dependencies (Was: /usr/bin/picard Re: bcbio will need another while - needs gatk)

[Steffen Möller]

Hi Nilesh,

Impressive as usual.

On 15.11.20 12:17, Nilesh Patra wrote:
> Hi,
>
> I packaged gsort and the rest of the dependency chain as needed by
> bcbio. Everything seems to build+pass its autopkgtests.
>
> The dependency chain is as follows:
>
> 1. golang-github-alexflint-go-scalar [1]
> 2. golang-github-alexflint-go-arg [2]    (depends on [1])
> 3. ggd-utils [3]   (depends on [2])
> 4. gsort [4]   (depends on [3] and [2])
>
> Please consider to review + upload to NEW
>
> PS:
> Simple gbp-buildpackage will not work on [1] since this follows new
> go-style guideline which drops pristine-tar[5]
> Hence the way here would be to run origtargz and run pdebuild w/o gbp
> You probably knew about this, but I re-iterated just in case you're
> not used to the new workflow for go-team and this saves your time
> while building this.
> Please consider my best of intentions here.
>
> [1]:
> https://salsa.debian.org/go-team/packages/golang-github-alexflint-go-scalar
> 
Just uploaded [1].
> [2]:
> https://salsa.debian.org/go-team/packages/golang-github-alexflint-go-arg
> 
> [3]: https://salsa.debian.org/med-team/ggd-utils
> 
> [4]: https://salsa.debian.org/med-team/gsort/
> 
> [5]:
> https://go-team.pages.debian.net/workflow-changes.html#wf-2017-11-pristine-tar
> 

With our short new queue I think I go back to waiting for a package's
acceptance prior to uploading a dependency.

Well done!

Steffen

Re: /usr/bin/picard Re: bcbio will need another while - needs gatk

[Steffen Möller]

Hi Andreas,

On 14.11.20 21:50, Andreas Tille wrote:
> Hi Steffen,
>
> On Sat, Nov 14, 2020 at 08:18:48PM +0100, Steffen Möller wrote:
>>> We have the workaround
>>>
>>>  /usr/lib/debian-med/bin/
>>>
>>> see for instance in eigensoft[1] and lots of other packages.  Simply
>>> provide this for picard-tools and make sure gatk users set the PATH
>>> accordingly.
>> Ah - that is good. Seems like I should read our policy document again.
> Not sure whether it is mentioned in policy.  I introduced this 2 or 3
> sprints ago.  Finally you are Uploader of at least one package using
> this technique. ;-P
;)
>> I just checked what my installation has in this directory ... and it
>> seems like I spotted a typo (or a creative fix of a typo elsewhere)
> ?
tranlate misses the "s"
>
>> $ ls -l /usr/lib/debian-med/bin/
>> total 0
>> lrwxrwxrwx 1 root root 26 Nov 12 16:57 tranlate ->
>> ../../../bin/fsa-translate
>>
>> $ apt-file search tranlate
>> fsa: /usr/lib/debian-med/bin/tranlate
>> $ apt-file search /usr/bin/translate
>> drslib: /usr/bin/translate_cmip3
>> openafs-client: /usr/bin/translate_et
>> translate: /usr/bin/translate
>>
>> I presume you would be happy for me to put there a link from cnvkit.py
>> (like bcbio expects it) to /usr/bin/cnvkit, right?
> Well, I think its orthogonal to my own happyness.  If it works for
> you just do the same as in the given example package.
I added that symlink and then patched bcbio to not expect the .py since
bcbio ignored the $PATH on this one.
>>> Simply ping the authors about this.  As far as I remember the last
>>> status was that sources are lost (?) and a backup needs to be found.
>> And if we just go for a non-free binary package for those jars? Just to
>> get somewhere?
> I personally consider maintaining non-free packages a pure nuisance and
> I'm not motivated to maintain such a package.  I think we should do
> *way* more effort to free *all* our non-free packages.
>
>> bcbio is in contrib anyway because of vienna-rna.
> Same here.  I do not see any record of attempts to free vienna-rna.
https://github.com/ViennaRNA/ViennaRNA/issues/97
>> And I do not think
>> these .jar files
>> will find much future adoption without a source backing, so this problem
>> will eradicate
>> itself.
> I will not try to stop anybody to maintain non-free packages - just do
> not trust on me in doing so.
>
>> There is also
>> bcbio.pipeline.config_utils.CmdNotFound: '_get_program_cmd' 'snpEff'
>> {'dir': '/usr/local/share/java/snpeff', 'jvm_opts': ['-Xms750m',
>> '-Xmx3g']} None
> I think we are pretty close to snpEff due to Pierre's efforts.

Nice!

This may be worth a sidenote - bcbio to me is something metaphorical. We
have it in the distribution already. And now we work to get all the
runtime-dependencies in to make it functional. And snpEff is pretty high
up (it interprets the importance of nucleotide variations, you need to
have identified these variants for that, first). So, my comment on
"snpeff" being invoked was to be interpreted as "see, here we are already".

>> ... picard-tools stuff snipped - I have nothing to say here ...
Works now.
>> Somehow Debian does barely complete any of these tests. There is always
>> something missing. And if it is tophat that upstream had asked us not to
>> support any more.
> I asked *several* times whether we need tophat and consequently will do
> a Python3 port.  Its perfectly fine for me to re-introduce tophat once
> it works with Python3.

Do other things first. I would not be completely surprised if this is
gone in one of the next updates to bcbio.

Steffen

Re: /usr/bin/picard Re: bcbio will need another while - needs gatk

[Andreas Tille]

Hi Steffen,

On Sun, Nov 15, 2020 at 02:39:03PM +0100, Steffen Möller wrote:
> >> I just checked what my installation has in this directory ... and it
> >> seems like I spotted a typo (or a creative fix of a typo elsewhere)
> > ?
> tranlate misses the "s"

Fixed in new upload.  BTW, it would be perfectly fine if you simply
fix such things in a team upload.

> >> I presume you would be happy for me to put there a link from cnvkit.py
> >> (like bcbio expects it) to /usr/bin/cnvkit, right?
> > Well, I think its orthogonal to my own happyness.  If it works for
> > you just do the same as in the given example package.
> I added that symlink and then patched bcbio to not expect the .py since
> bcbio ignored the $PATH on this one.

Fine for me.  Regarding the .py extension I became quite relaxed.  See
our package template:

   
https://salsa.debian.org/med-team/community/package_template/-/blob/master/debian/lintian-overrides

> > I think we are pretty close to snpEff due to Pierre's efforts.
> 
> Nice!
> 
> This may be worth a sidenote - bcbio to me is something metaphorical. We
> have it in the distribution already. And now we work to get all the
> runtime-dependencies in to make it functional. And snpEff is pretty high
> up (it interprets the importance of nucleotide variations, you need to
> have identified these variants for that, first). So, my comment on
> "snpeff" being invoked was to be interpreted as "see, here we are already".

Snpeff is wanted from several sided.  I really hope we get it soon.
 
Kind regards

   Andreas. 

-- 
http://fam-tille.de

[RFS] lighter

[Nilesh Patra]

Please grant DM access for lighter :-)

(Daily RFS have started becoming annoying now :/ hence keeping low
verbosity)

Nilesh

Packaging ITK version 5

[Steven Robbins]

Hi,

I have a bit of time today and thought I'd look into packaging ITK 5.1.1.

My thought is to upload to experimental first.  I don't see any "experimental" 
branch in salsa, but maybe I can just create one?  Or would it be better to 
make an itk5 branch?

Also, I recall that someone (Gert, I believe) once proposed dropping the 
python packages for ITK 5.  I can't find the email just now but the gist of it 
was (in my recollection) that anyone really using the python wrappers for ITK 
is likely to need to carefully select the bits that need wrapping.  So the 
provided packages aren't of high value, but they do cause many of the build 
issues for debian.  So my thought is to drop the python package.

Thoughts on any of the above?
-Steve


signature.asc
Description: This is a digitally signed message part.

done Re: [RFS] lighter

[Steffen Möller]

Thanks!

On 15.11.20 18:48, Nilesh Patra wrote:
> Please grant DM access for lighter :-)
>
> (Daily RFS have started becoming annoying now :/ hence keeping low
> verbosity)
>
> Nilesh

Re: Packaging ITK version 5

[Andreas Tille]

Hi Steven,

On Sun, Nov 15, 2020 at 01:07:26PM -0600, Steven Robbins wrote:
> I have a bit of time today and thought I'd look into packaging ITK 5.1.1.

Thanks for caring for itk.
 
> My thought is to upload to experimental first.  I don't see any 
> "experimental" 
> branch in salsa, but maybe I can just create one?  Or would it be better to 
> make an itk5 branch?

I admit I don't mind since I never touched itk.  If Gerd (and those who
recently contributed) are OK with this that's fine.
 
> Also, I recall that someone (Gert, I believe) once proposed dropping the 
> python packages for ITK 5.  I can't find the email just now but the gist of 
> it 
> was (in my recollection) that anyone really using the python wrappers for ITK 
> is likely to need to carefully select the bits that need wrapping.  So the 
> provided packages aren't of high value, but they do cause many of the build 
> issues for debian.  So my thought is to drop the python package.
> 
> Thoughts on any of the above?

I'm not a user of ITK but my general experience is that users are keen
on all interfaces that are provided upstream.  But its just an uneducated
guess of mine in respect of ITK.

Kind regards

  Andreas.


-- 
http://fam-tille.de