Re: MRtrix3

[Julien Lamy]

Le 03/03/2021 à 20:13, Andreas Tille a écrit :

On Wed, Mar 03, 2021 at 04:45:02PM +0100, Julien Lamy wrote:


Would the following solution be acceptable per Debian policy:
- Keep dirsplit and its dependency gen_scheme installed in
usr/lib/mrtrix3/bin (current situation)
- Install everything else in usr/bin and resolve conflicts if/when they
happen


I do not see any actual advantage between symlinks in /usr/bin and
the binaries somewhere else or the binaries directly in /usr/bin.
I do not mind actually - just do whatever works.

Just a slight hint that there is a Blends-workaround for name
space conflicts which is described for instance here:

 https://salsa.debian.org/med-team/plink/-/blob/master/debian/README.Debian


Thank you all for the advice. Current HEAD builds, has been 
routine-updated and is lintian-clean; unless I missed something, it is 
probably ready for upload.

Re: MRtrix3

[Andreas Tille]

On Thu, Mar 04, 2021 at 12:32:30PM +0100, Julien Lamy wrote:
> Le 03/03/2021 à 20:13, Andreas Tille a écrit :
> > Just a slight hint that there is a Blends-workaround for name
> > space conflicts which is described for instance here:
> > 
> >  
> > https://salsa.debian.org/med-team/plink/-/blob/master/debian/README.Debian
> 
> Thank you all for the advice. Current HEAD builds, has been routine-updated
> and is lintian-clean; unless I missed something, it is probably ready for
> upload.

Hmmm, but it is to late to meet the freeze deadline.  So I wonder
whether an upload of this new version is sensible.

Kind regards

 Andreas.
 

-- 
http://fam-tille.de

Re: MRtrix3

[Nilesh Patra]

On Thu, 4 Mar, 2021, 5:16 pm Andreas Tille,  wrote:

> On Thu, Mar 04, 2021 at 12:32:30PM +0100, Julien Lamy wrote:
> > Le 03/03/2021 à 20:13, Andreas Tille a écrit :
> > > Just a slight hint that there is a Blends-workaround for name
> > > space conflicts which is described for instance here:
> > >
> > >
> https://salsa.debian.org/med-team/plink/-/blob/master/debian/README.Debian
> >
> > Thank you all for the advice. Current HEAD builds, has been
> routine-updated
> > and is lintian-clean; unless I missed something, it is probably ready for
> > upload.
>
> Hmmm, but it is to late to meet the freeze deadline.  So I wonder
> whether an upload of this new version is sensible.


It isn't unless we have autopkgtest for it. But in any case, at this point,
I'll vote for a "no" on new upstream releases to unstable

Nilesh

>
>

Bug#984477: marked as done (libbio-variation-perl: missing Breaks+Replaces: bioperl (<< 1.7.3))

[Debian Bug Tracking System]

Your message dated Thu, 04 Mar 2021 13:18:23 +
with message-id 
and subject line Bug#984477: fixed in libbio-variation-perl 1.7.5-2
has caused the Debian Bug report #984477,
regarding libbio-variation-perl: missing Breaks+Replaces: bioperl (<< 1.7.3)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
984477: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984477
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libbio-variation-perl
Version: 1.7.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libbio-variation-perl.
  Preparing to unpack .../048-libbio-variation-perl_1.7.5-1_all.deb ...
  Unpacking libbio-variation-perl (1.7.5-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-eyjeT8/048-libbio-variation-perl_1.7.5-1_all.deb 
(--unpack):
   trying to overwrite '/usr/bin/bp_flanks', which is also in package bioperl 
1.7.2-3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

IIRC bioperl 1.7.3 is the version that got split up into several packages,
therefore the existing
  Breaks+Replaces: libbio-perl-perl (<= 1.7.2)
are also insufficiently versioned (should be (<< 1.7.3) as well).

cheers,

Andreas


bioperl-run_1.7.3-6.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: libbio-variation-perl
Source-Version: 1.7.5-2
Done: Andreas Tille 

We believe that the bug you reported is fixed in the latest version of
libbio-variation-perl, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 984...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Tille  (supplier of updated libbio-variation-perl 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 04 Mar 2021 13:55:37 +0100
Source: libbio-variation-perl
Architecture: source
Version: 1.7.5-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 

Changed-By: Andreas Tille 
Closes: 984477
Changes:
 libbio-variation-perl (1.7.5-2) unstable; urgency=medium
 .
   * Team upload.
   * Fix maintainer address
   * Add debian/salsa-ci.yml
   * Breaks+Replaces: bioperl (<< 1.7.3)
 Closes: #984477
Checksums-Sha1:
 2691b1240f8113942a21e750644d2cd284324e28 2286 libbio-variation-perl_1.7.5-2.dsc
 da8ec9b9f37993aebea0805f57b8a6b1f3328f3e 2052 
libbio-variation-perl_1.7.5-2.debian.tar.xz
 e497eedd383a5c47cf3ecd69f0c7d5a1129fbafe 7420 
libbio-variation-perl_1.7.5-2_amd64.buildinfo
Checksums-Sha256:
 398f6a65c2b11255b53191b6b80705e3057dce3185ec4d9781c23185be741e4f 2286 
libbio-variation-perl_1.7.5-2.dsc
 80892316d8c5916336dae5c00b71cd4efcaa36e665a44a4d2529b31af77f4ed4 2052 
libbio-variation-perl_1.7.5-2.debian.tar.xz
 93fd5f6e1be944d84cf9a98ae5d2f0ca669acc820d0f99e4f2bdc969ba13f48b 7420 
libbio-variation-perl_1.7.5-2_amd64.buildinfo
Files:
 95819385a30bb2c3a9422e585cf669be 2286 perl optional 
libbio-variation-perl_1.7.5-2.dsc
 a9554a36af420584e21916fae8778dde 2052 perl optional 
libbio-variation-perl_1.7.5-2.debian.tar.xz
 9eebf28a9a9b33b77653193fe1859cbd 7420 perl optional 
libbio-variation-perl_1.7.5-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmBA2SQRHHRpbGxlQGRl
Ymlhbi5vcmcACgkQV4oElNHGRtGV/g//UnswyCARmFpiEqPQC1/QjBvJpyTweoVo
IJdfM01imVFjd2LC1dPwt+SUchnsbD9BYsbiJNrjxILsn2Kb7K51uPZ8sB/ZSnos
2MAkwwdikiX3NF8XXWd5uYjifpM56SXAidE4WF795NO/LnKK8IG2g28DaAYPPPZ1
44hzgIQ4frigC7TpAf7mqnBYvbyzctHonLqF2Mq8462rf8qUY8cebZ5OibhmvdGC
15/A7UfVRVCl5GD3tRlBbwEKSQhPIYnCesrjY/FpcvA57XSe6e70nwu3raMPITA+
qvGgpKYJ00XvdGRzCQvDrczDyazG+bjT8UvapvfWn8lWIbrw1Q1uoeoHXH3d5WwC
5jWKKfHHS9Oi1q8XtAKatRcNqxgZL5OSpN5OQjoaEScd2X4hLHnNukUUbqlFbCo2
7VCNr11r2

Re: "Entry: NA" in debian/upstream/metadata

[rhkramer]

On Wednesday, March 03, 2021 11:39:41 AM Matus Kalas wrote:

> P.S.: Could you please leave all the contents in when replying to the
> thread, so that others can reply to previously mentioned points without
> having to read every single email in the thread and possibly breaking
> linearity of it? I agree that's it not ecological to broadcast the same
> text all around the globe again and again, but there are other solutions
> than emails that handle that without compromising. Many thanks!

From the peanut gallery, and as someone not participating in this thread, I 
have a problem with this.

First of all (but maybe least of all) it is in conflict with the generally 
accepted "rules" for replying to emails.

More relevant is that it causes me to read a lot of extraneous stuff that is 
somehow already resolved, no longer an issue.  I want to easily and quickly 
find the stuff that is still under discussion.

I guess I don't care about this thread, but I hope it doesn't become the 
standard practice, although it sometimes seems that way (especially on debian-
user, which, I know, is not this list).

Re: "Entry: NA" in debian/upstream/metadata

[Andrius Merkys]

Hi Charles,

On 2021-03-04 07:06, Charles Plessy wrote:
> how about YAML's null value for entries for which it was confirmed that
> the information does not exist ?

This was my initial idea. I do not know much about YAML, but at least
Perl YAML implementations see no difference between different ways of
specifying undefined/null in YAML. I tried both YAML and YAML::XS
modules, and both seemingly do the same:

perl -MYAML -MData::Dumper -we 'print Dumper Load($ARGV[0])' 'field: ~'
$VAR1 = {
  'field' => undef
};

perl -MYAML -MData::Dumper -we 'print Dumper Load($ARGV[0])' 'field:'
$VAR1 = {
  'field' => undef
};

perl -MYAML -MData::Dumper -we 'print Dumper Load($ARGV[0])' 'field: !!null'
$VAR1 = {
  'field' => undef
};

Maybe I am doing something wrong, but currently I am under impression
that YAML does not have enough flavors of "unknown" to cater our needs.

Best,
Andrius

Re: Outreachy project: complete workflows of tools

[Andreas Tille]

Dear Tássia,

On Wed, Mar 03, 2021 at 03:21:18PM -0800, Tassia Camoes Araujo wrote:
> Hi Debian-Med team!
> 
> -- this should be a reply to the sprint report, sorry I was not in the
> list at the moment --
> 
> One of the topics we discussed was to have an additional Outreachy
> intern to work on creating educational material, such as video
> tutorials, to showcase workflows in the field using Debian-Med tools. We
> brainstormed about qime, microbiome, but the idea would be to let the
> student free to pick a workflow she/he has some experience with. 

Thanks a lot for picking this up.
 
> Reading the list archive I saw a message by Tony Travis as a great
> example of solving biological problems with our tools: "I use the
> software you've packaged for my own work on the molecular genetics of
> drought-tolerance and Nitrogen-use-efficiency in Rice and for studies of
> the micro-virome of Tsetse files and Mosquitoes as well as for the
> cancer genomics work on the cluster at the Mario Negri Institute in
> Milan."
> 
> I volunteer to help to shape the proposal, and whatever else you need
> (with my limited knowledge in the field) to make this come true.

If I understood you correctly your question to Tony was whether he might
like to volunteer to support drafting an Outreachy proposal.  Guessing
from Tony's response to your mail this was not totally clear to him. 

I personally would support this proposal "mentally" (in terms of proof
reading and lending some helping hand if really needed) but I've just
issued the QA proposal and I'm not permitted to serve as mentor in more
than one project.

Steffen, would you step in here?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Outreachy project: complete workflows of tools

[Tony Travis]

On 04/03/2021 16:54, Andreas Tille wrote:

[...]
If I understood you correctly your question to Tony was whether he might
like to volunteer to support drafting an Outreachy proposal.  Guessing
from Tony's response to your mail this was not totally clear to him.


Hi, Andreas.

You're right, I was just suggesting that the Bio-Linux documentation and 
the "Introduction to Bio-Linux" tutorial I helped Tim Booth to create in 
particular might be a useful starting point for an 'Outreachy' projeect.


I'm planning to re-write the tutorial, which includes QIIME, for my 
Debian-Med version of Bio-Linux, but it would be really helpful if 
someone is interested in doing that as part of an 'Outreachy' project.


Sorry, I misunderstood Tássia's email.

  Tony.

--
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. +44(0)19755 63548http://minke-informatics.co.uk
mob. +44(0)7985 078324mailto:tony.tra...@minke-informatics.co.uk

Re: "Entry: NA" in debian/upstream/metadata

[Steffen Möller]

Am 04.03.21 um 17:12 schrieb Andrius Merkys:
> Hi Charles,
>
> On 2021-03-04 07:06, Charles Plessy wrote:
>> how about YAML's null value for entries for which it was confirmed that
>> the information does not exist ?
> This was my initial idea. I do not know much about YAML, but at least
> Perl YAML implementations see no difference between different ways of
> specifying undefined/null in YAML. I tried both YAML and YAML::XS
> modules, and both seemingly do the same:
>
> perl -MYAML -MData::Dumper -we 'print Dumper Load($ARGV[0])' 'field: ~'
> $VAR1 = {
>   'field' => undef
> };
>
> perl -MYAML -MData::Dumper -we 'print Dumper Load($ARGV[0])' 'field:'
> $VAR1 = {
>   'field' => undef
> };
>
> perl -MYAML -MData::Dumper -we 'print Dumper Load($ARGV[0])' 'field: !!null'
> $VAR1 = {
>   'field' => undef
> };
>
> Maybe I am doing something wrong, but currently I am under impression
> that YAML does not have enough flavors of "unknown" to cater our needs.

This reminds me of the early days of my computer science education with
the question if {} and {{}} are the same thing. They are not. My first
idea was that the parser is to blame, but the example at
https://yaml.org/type/null.html makes the same
what-I-consider-to-be-a-mistake. I am a fan to use the ~ as a proper NA
substitute but there is little point if we cannot distinguish it from
nothing when parsing it.

Somewhere else was the suggestion made to also add a time stamp. This
makes perfect sense for the NA/~ and in that case, if that date was
specified, we know that unknown is a confirmed unknown. For entries that
are found, we should possibly just rely on git blame in salsa.

Thank you all!

Steffen

Re: Outreachy project: complete workflows of tools

[Steffen Möller]

Am 04.03.21 um 22:09 schrieb Tony Travis:
> On 04/03/2021 16:54, Andreas Tille wrote:
>> [...]
>> If I understood you correctly your question to Tony was whether he might
>> like to volunteer to support drafting an Outreachy proposal.  Guessing
>> from Tony's response to your mail this was not totally clear to him.
>
> Hi, Andreas.
>
> You're right, I was just suggesting that the Bio-Linux documentation
> and the "Introduction to Bio-Linux" tutorial I helped Tim Booth to
> create in particular might be a useful starting point for an
> 'Outreachy' projeect.
>
> I'm planning to re-write the tutorial, which includes QIIME, for my
> Debian-Med version of Bio-Linux, but it would be really helpful if
> someone is interested in doing that as part of an 'Outreachy' project.
>
> Sorry, I misunderstood Tássia's email.

I am very confident that Tony would be a wonderful mentor. I happily
help by co- or co-co-mentoring - we had discussed Qiime at the very last
minutes of our Sprint if I recall correctly.

So, with Tony having gone the conda route a while back when our recent
Debian packages have not yet been existing, I see this as particularly
valuable for Tássia to both experience and compare.

Best,

Steffen

Re: guix-based installation of pigx-rnaseq - works

[zimoun]

Hi,

On Wed, 03 Mar 2021 at 20:45, Steffen Möller  wrote:

>> What would be nice for Debian instead of
>> ?
> The updates of Debian's packages and those of guix are not synchronized.
> And once something is in a regular Debian release, the Debian package
> likely points to an older version of the same in guix. It would hence be
> preferable to have an unversioned page to point to - which then lists
> all the versions available for that package.

Something like that:

1: 


?


>> And where could I find a an example on how the others do?
>
> https://tracker.debian.org/pkg/vim

Something equivalent is the Guix Data Service, as mentioned in [1].



Cheers,
simon

Re: guix-based installation of pigx-rnaseq - works

[zimoun]

Hi Pjotr,

On Wed, 03 Mar 2021 at 22:16, Pjotr Prins  wrote:

> I love Debian, but Guix packages and containers are the cats whiskers!
> It is brilliant to have them both. I have no need for conda.

Now this works:

  # apt install guix
  $ guix install hello

and since Vagrant sent the announce on Guix Devel, I have on my TODO to
try the contrary: install Debian packages on Guix System,

  # guix install dpkg
  # dpkg 

Because packages are really hard to package (I have in mind Machine
Learning stuff) and they will not be included soon, IMHO.  Then I could
remove my Guix on the top of Debian and simply have Debian inside
Guix. ;-)


Cheers,
simon

Re: guix-based installation of pigx-rnaseq - works

[Steffen Möller]

Am 05.03.21 um 01:18 schrieb zimoun:
> Hi Pjotr,
>
> On Wed, 03 Mar 2021 at 22:16, Pjotr Prins  wrote:
>
>> I love Debian, but Guix packages and containers are the cats whiskers!
>> It is brilliant to have them both. I have no need for conda.
> Now this works:
>
>   # apt install guix
>   $ guix install hello
>
> and since Vagrant sent the announce on Guix Devel, I have on my TODO to
> try the contrary: install Debian packages on Guix System,
>
>   # guix install dpkg
>   # dpkg 
This is darn cool.
> Because packages are really hard to package (I have in mind Machine
> Learning stuff) and they will not be included soon, IMHO.

https://tracker.debian.org/pkg/pytorch

But all the CI with GPUs are yet not clear if I got this right.

> Then I could
> remove my Guix on the top of Debian and simply have Debian inside
> Guix. ;-)
Could we make this somehow visible on popcon.debian.org?

Best,

Steffen

Upstream permission needed to package machine learning preconditions (Was: guix-based installation of pigx-rnaseq - works)

[Andreas Tille]

Hi

On Fri, Mar 05, 2021 at 01:18:37AM +0100, zimoun wrote:
> 
> Because packages are really hard to package (I have in mind Machine
> Learning stuff) and they will not be included soon, IMHO.  Then I could
> remove my Guix on the top of Debian and simply have Debian inside
> Guix. ;-)

Apropos hard to package Machine Learning stuff.  I recently intended to
package cython-blis[1] since it is needed by recent versions of
python-thinc.  It turns out that my packaging attemt[2] is not
specifically hard from a technical point of view (at least the package
builds and passes its test - it needs to be verified via benchmarking
whether it is as performant as possible) there is some non-technical
issue I would like you to read:

   https://github.com/explosion/cython-blis/issues/32 

I have collected opinions of other Debian Developers who have touched
that package before inside my ITP bug[1].  My intention is to open a new
discussion with upstream and it would be really great if you would join
me in this from a different perspective than "just another Debian
developer".  So my question is:  Would you join me in this discussion to
get "permission" to package cython-blis (which is strictly speaking not
needed license wise but my per Debian policy I should not package
anything if upstream does not want me to do so).

Kind regards

 Andreas.

[1] http://bugs.debian.org/984497
[2] https://salsa.debian.org/science-team/python-cython-blis

-- 
http://fam-tille.de