Bug#961331:

[Sao I Kuan]

block 956033 by -1
thanks

Bug#961331:

[Sao I Kuan]

Control: block 956033 by -1
thanks

Processed:

[Debian Bug Tracking System]

Processing control commands:

> block 956033 by -1
Bug #956033 [wnpp] ITP: idseq-bench -- Benchmark generator for the IDseq Portal
956033 was not blocked by any bugs.
956033 was not blocking any bugs.
Added blocking bug(s) of 956033: 961331

-- 
956033: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956033
961331: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961331
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#956033: RFS: idseq-bench [ITP]

[Sao I Kuan]

Hi,

I'm looking for a sponsor for the package:
  * idseq-bench (#956033)

The package is on:
https://salsa.debian.org/med-team/idseq-bench

The package has a dependency which is waiting in NEW queue: insilicoseq[1,2].

[1] https://bugs.debian.org/961331
[2] https://ftp-master.debian.org/new/insilicoseq_1.4.6-1.html

Please consider to review and sponsor this. Any kind of suggestions
are appreciated.

Thank you!

Sincerely,

Sao I Kuan
saoik...@gmail.com

Bug#964191: RoSA ante portas - happily pass this on

[Andreas Tille]

Hi

(Dylan, please see below)

On Fri, Jul 03, 2020 at 09:36:53PM +0200, Steffen Möller wrote:
> 
> RoSA is one of the workflow packages, i.e. one of the packages
> motivating the sprint. It is in salsa now. Yeah!
> 
> This is both R and python in one source package and ... it took me too
> much time of my time today, such that I don't want to continue investing
> into it. On salsa.d.o/med-team/rosa we have something that compiles and
> packages but does not test because somehow my attempts to set the paths
> have failed miserably.

Would you mind explaining what you did for a build time test?  I've
added an autopkgtest for the R part.

> Also, the dependencies liested in|conda_env.yml
> still need to be translated into the Debian package names.

I admit I'm wondering how all these dependencies in conda_env.yml are
used.  For instance the R packages do not seem to be needed:  dh-make-R 
does not find any needed dependencies and the autopkgtest is passing.

@Dylan: Any idea how to fix

E: r-other-rosa: requires-r-api
N: 
N:This package ships a site library for the R programming language package
N:but does not declare the R API r-api- as a package prerequisite.
N:
N:With the dh sequencer, please use --buildsystem=R in debian/rules and
N:add the substitution variable ${R:Depends} to the Depends field in
N:debian/control.
N:
N:Refer to https://wiki.debian.org/Teams/r-pkg-team for details.
N:
N:Severity: error
N:
N:Check: languages/r/site-library
N: 


Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#964191: RoSA ante portas - happily pass this on

[Dylan Aïssi]

Hi Andreas,

Le sam. 4 juil. 2020 à 09:43, Andreas Tille  a écrit :
> @Dylan: Any idea how to fix
>
> E: r-other-rosa: requires-r-api

\o/ this tag is finally useful :-)

I pushed a change that should fix this issue. I was not able to test
because r-cran-lsd is not available (still in NEW). Could you try this
change for me?

Best,
Dylan

Bug#964243: ITP: PyRDFA -- RDFa distiller and parser library for Python

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : python-rdfa
  Version  : 3.5.2
  Upstream Author  : Ivan Herman 
* Url  : https://www.w3.org/2007/08/pyRdfa/#distribution
* Licenses : W3C
  Programming Lang : Python
  Section  : python

 PyRDFA is an RDFa 1.1 parser,
 also referred to as an RDFa distiller.
 .
 Resource Description Framework in Attributes (RDFa)
 is a W3C Recommendation
 that adds a set of attribute-level extensions
 to HTML, XHTML and various XML-based document types
 for embedding rich metadata within Web documents.

This package is needed for newer releases of python-rdflib.

I plan to maintain this package in the semweb team
,
with code hosted in the collaborative Debian section of Salsa:

 https://salsa.debian.org/debian/python-rdfa.git

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#964191: RoSA ante portas - happily pass this on

[Andreas Tille]

Hi Dylan,

On Sat, Jul 04, 2020 at 10:11:23AM +0200, Dylan Aïssi wrote:
> 
> Le sam. 4 juil. 2020 à 09:43, Andreas Tille  a écrit :
> >
> > E: r-other-rosa: requires-r-api
> 
> \o/ this tag is finally useful :-)

Sure it is!
 
> I pushed a change that should fix this issue. I was not able to test
> because r-cran-lsd is not available (still in NEW). Could you try this
> change for me?

While I think your changes are pretty sensible it does not solve the
problem.

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Bug#964191: RoSA ante portas - happily pass this on

[Dylan Aïssi]

Le sam. 4 juil. 2020 à 11:27, Andreas Tille  a écrit :
>
> While I think your changes are pretty sensible it does not solve the
> problem.
>

:-( I will investigate this again later today


Dylan

Processed: ITP: pyrdfa -- RDFa distiller and parser library for Python

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 964243 ITP: pyrdfa -- RDFa distiller and parser library for Python
Bug #964243 [wnpp] ITP: PyRDFA -- RDFa distiller and parser library for Python
Changed Bug title to 'ITP: pyrdfa -- RDFa distiller and parser library for 
Python' from 'ITP: PyRDFA -- RDFa distiller and parser library for Python'.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
964243: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964243
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#859180: marked as done (ITA: fonts-humor-sans -- Font that looks like handwritten text)

[Debian Bug Tracking System]

Your message dated Sat, 04 Jul 2020 11:33:41 +
with message-id 
and subject line Bug#859180: fixed in fonts-humor-sans 1.0-4
has caused the Debian Bug report #859180,
regarding ITA: fonts-humor-sans -- Font that looks like handwritten text
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.)


-- 
859180: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859180
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wnpp
Severity: normal
--- End Message ---
--- Begin Message ---
Source: fonts-humor-sans
Source-Version: 1.0-4
Done: Hideki Yamane 

We believe that the bug you reported is fixed in the latest version of
fonts-humor-sans, 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 859...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Hideki Yamane  (supplier of updated fonts-humor-sans 
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: Sat, 04 Jul 2020 20:09:13 +0900
Source: fonts-humor-sans
Architecture: source
Version: 1.0-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Fonts Task Force 
Changed-By: Hideki Yamane 
Closes: 859180
Changes:
 fonts-humor-sans (1.0-4) unstable; urgency=medium
 .
   * debian/control
 - Set new maintainer and uploader (Closes: #859180)
 - Update Vcs-* to point salsa.debian.org
 - Set Rules-Requires-Root: no
 - Set Standards-Version: 4.5.0
 - Drop debhelper and set debhelper-compat (= 13)
   * Drop debian/compat
   * debian/copyright
 - Add myself for copyright holder for debian packaging
   * Add debian/salsa-ci.yml
   * Trim trailing whitespace.
   * Use secure URI in Homepage field.
Checksums-Sha1:
 1fb94536517508e88a3742e33400cf31f645f7c2 1978 fonts-humor-sans_1.0-4.dsc
 79b04b781d647059d54606e57eae797b15bbbfea 3676 
fonts-humor-sans_1.0-4.debian.tar.xz
 278583ab08186dd71be78af6eeaba94723c322eb 5636 
fonts-humor-sans_1.0-4_amd64.buildinfo
Checksums-Sha256:
 123db0f4876e5401c56477353687d87c16f99d8cc9ccad5f8bafb78fbabd2cd3 1978 
fonts-humor-sans_1.0-4.dsc
 a9130cf610c69933117b035516a9de0c5d6d36efe9a7500644657b6e3a2a4b29 3676 
fonts-humor-sans_1.0-4.debian.tar.xz
 47e730fd358acb5ee5b06a65a148367368a1a220ab9bac95c9025028b74568fe 5636 
fonts-humor-sans_1.0-4_amd64.buildinfo
Files:
 b4af50e4ddfd3e22da49bc51b431c4d4 1978 fonts optional fonts-humor-sans_1.0-4.dsc
 04d94368341bbd5ecf1d465faf5e59aa 3676 fonts optional 
fonts-humor-sans_1.0-4.debian.tar.xz
 d3767a6d26f33cd9b54fef05b1ac23f9 5636 fonts optional 
fonts-humor-sans_1.0-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEWOEiL5aWyIWjzRBMXTKNCCqqsUAFAl8AZfcACgkQXTKNCCqq
sUBHLhAAj8ICmarTcsSFjSAMNvO7zVd8pB+L+c4SpnWO9JITcTN+MSfWILskJ3oW
kBw/m4j0wpd7zZPRPPm1ic9kkykBAVuZVw+AWTFgECqbuVfSmKABM55geOa3SQau
qMxCX/s2QbJWvi1pPyJ5p3LVO0RW/zqqQUsZQwljQ3LD5W9FwvwRmqQaqrMJgPEP
KdmQ3vwrfuLL7qlgBcUqjSUizoOVDGF0bbaiRadhboBvcb71hRP6ixbj9jvQlis0
lqmvQotrNUFZaDeu5C5ZGmVxnYj5+i8y3LRRHERMB0x0BNInorsUadgaWz4qzk+q
M9623qKlwsFsHH4RuzwyiUeZ3d6OZOeXgwNCaOodr1s7KqQkhOIrMbZmqJzPO0pu
Nt5Bxmg1NyKXgGosZAv+3K83VVr+fsflbOZy99n2YyTwWLDd2xs6588yGRhPNt/1
3TzO+HV+DvRX2y8ep2jEOzDmssxJYxsKR87txJA5GLwEcZvcSUD1oW1vQ2RtClEb
LJCrkaPQrsOTAOSTT6GjtB4YhX6TlyWF9QdABPnTXr3jX7MFmTAu3R65CahzuMGz
HCXucX+FI8ig1vCNy97PzWdS1UXyV5JXQo6Cu/VHI6d/S7I4wMYElICa3y/ugtRG
FG/UM/X53Nows+xBr4abVmMCNW+d/PC+qVSPuPrRN5oDeTXh+1k=
=/XSE
-END PGP SIGNATURE End Message ---

Bug#914665: marked as done (ITA: fonts-tiresias -- Fonts for the visually impaired)

[Debian Bug Tracking System]

Your message dated Sat, 04 Jul 2020 12:03:31 +
with message-id 
and subject line Bug#914665: fixed in fonts-tiresias 0.1-6
has caused the Debian Bug report #914665,
regarding ITA: fonts-tiresias -- Fonts for the visually impaired
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.)


-- 
914665: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914665
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: wnpp
Severity: normal

I orphan this package now. (Upstream homepage dead, no new place for it
found)

Maintaining a package requires time and skills. Please only adopt this
package if you are *sure* you will have enough time and attention to
work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.
--- End Message ---
--- Begin Message ---
Source: fonts-tiresias
Source-Version: 0.1-6
Done: Hideki Yamane 

We believe that the bug you reported is fixed in the latest version of
fonts-tiresias, 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 914...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Hideki Yamane  (supplier of updated fonts-tiresias 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: Sat, 04 Jul 2020 20:46:19 +0900
Source: fonts-tiresias
Architecture: source
Version: 0.1-6
Distribution: unstable
Urgency: medium
Maintainer: Debian Fonts Task Force 
Changed-By: Hideki Yamane 
Closes: 914665
Changes:
 fonts-tiresias (0.1-6) unstable; urgency=medium
 .
   * debian/control
 - Set new maintainer and uploaders (Closes: #914665)
 - Drop debhelper, set debhelper-compat (= 13)
 - Split Build-Depends to Build-Depends-Indep
 - Set Standards-Version: 4.5.0
 - Drop upstream Homepage:, it's dead
 - Add Vcs-*
 - Set Rules-Requires-Root: no
   * debian/install
 - Move to /usr/share/fonts/truetype/tiresias, "fonts-" is useless
   * debian/copyright
 - Convert to copyright format 1.0
   * Drop debian/compat
   * Add debian/salsa-ci.yml
Checksums-Sha1:
 2e82daed6d912e5734f0fc15d874692bf544c486 1940 fonts-tiresias_0.1-6.dsc
 d549c97d3971d9b13099aecb8ebd2fd7e2eb4a9d 3188 
fonts-tiresias_0.1-6.debian.tar.xz
 818410d5d8c8c64bdb64dc6750efbd7df8d358c1 5660 
fonts-tiresias_0.1-6_amd64.buildinfo
Checksums-Sha256:
 faafcee0664887fa60dd1c8cf255fc562c65fbcd6230ced7d571d686fb082b7d 1940 
fonts-tiresias_0.1-6.dsc
 ffc291376b92971f2ad71e9bb9a0bb6707b29d162441aad4dc0f0e0639cba729 3188 
fonts-tiresias_0.1-6.debian.tar.xz
 875893614d836ca29b86f39bd7e9272e4cf34fa75a3044500857e4a643f4379e 5660 
fonts-tiresias_0.1-6_amd64.buildinfo
Files:
 6367c09e15e248fc65858d7edcfab7a4 1940 fonts optional fonts-tiresias_0.1-6.dsc
 24929866e8b8b791894cd6f82d4882b9 3188 fonts optional 
fonts-tiresias_0.1-6.debian.tar.xz
 24acedb6930fbd033c4fbfef5c8ca459 5660 fonts optional 
fonts-tiresias_0.1-6_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEWOEiL5aWyIWjzRBMXTKNCCqqsUAFAl8AbaUACgkQXTKNCCqq
sUCyRw/9GwQqYsLZW3OXBjuZXuvhRhHIFtKd1SyiFVsm+Wbx3qeOF/uDjBBy7j8z
7WJVUEhuRrSZgJfxUgZaKiR9kaj8RlY7Gc9RcmzU7ftKLiD2eJ1yTADnU6a1QRSl
sDJJQ/5yfEnIMokXnE4Ousxasa2LJRAL8OvDL8rX4kSDZ7VALFBQRyOs2iTTNenm
iBNGzJnoxAOc3cYbSMiX5SbN8wvNw76eL8R5EA1eR7nD8IgHQMVxYRygaOe00Qbq
fiVX0AgNkzDO6vAEOLBPdqeEYR9fJYdJdyXs5IXcvfyKupD5ILMGvMNOscsGyIUK
cxfgsMtvQ0gi6+x7jK1lgEwJw+U361/igQntbyL/AiVFWDcuEsap2OPmHotNj2l0
C6H90vuKdvsL8YgHdlcO4go1dzH6/jHhr8sg6+UokikEsD+2XHaSopR1dkuWztZT
b1pCsmGCHKmmisVzqs7PaF6g96+jjFcSwN0krctvXc3uwBgWBcVplfm5ox5tJUUL
aAEeMmQRCH63qBWKo5vmOAsFCnc7ogJwCFkVUzuPLhDMmZRSLfeCG6fXHIIK88ov
Rml+3NZw4r++Ejs2e7kaZpuV0+WA+iUuPk3bmrOD5+iy8Gk98kxJmddZNHPPApuS
kPjrceNRFjdKDl7nN07UXzW1XPvxi14Mcly7z+Yitp0Xi1ATmSU=
=nQBt
-END PGP SIGNATURE End Message ---

Bug#963480:

[Sao I Kuan]

Control: retitile -1 ITP: python-duckpy -- A simple Python library for
searching on DuckDuckGo

Processed:

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 ITP: python-duckpy -- A simple Python library for
Bug #963480 [wnpp] ITP: duckpy -- A simple Python library for searching on 
DuckDuckGo
Changed Bug title to 'ITP: python-duckpy -- A simple Python library for' from 
'ITP: duckpy -- A simple Python library for searching on DuckDuckGo'.

-- 
963480: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963480
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#963480:

[Sao I Kuan]

Control: retitle -1 ITP: python-duckpy -- A simple Python library for
searching on DuckDuckGo

Bug#963480: RFS: python-duckpy [ITP]

[Sao I Kuan]

Hi,

I'm looking for a sponsor for the package:
  *python-duckpy (#963480)

The package is on:
https://salsa.debian.org/med-team/python-duckpy

The package is dependency of benten[1,2].

[1] https://github.com/rabix/benten
[2] https://bugs.debian.org/963743

The package is lintian-clean.

Please consider to review and sponsor this. Any kind of suggestions
are appreciated.

Thank you!

Sincerely,

Sao I Kuan
saoik...@gmail.com

Bug#963234: RFS: cwlformat [ITP]

[Sao I Kuan]

Hi,

I'm looking for a sponsor for the package:
   cwlformat (#963234)

The package is on:
https://salsa.debian.org/med-team/cwlformat

The package is dependency of benten[1,2].

[1] https://github.com/rabix/benten
[2] https://bugs.debian.org/963743

The package is lintian-clean. The package does have autopkgtest and passed well.

Please consider to review and sponsor this. Any kind of suggestions
are appreciated.

Thank you!

Sincerely,

Sao I Kuan
saoik...@gmail.com

Processed:

[Debian Bug Tracking System]

Processing control commands:

> block 963743 by -1
Bug #963743 [wnpp] ITP: benten -- Language server for Common Workflow Language 
documents
963743 was not blocked by any bugs.
963743 was not blocking any bugs.
Added blocking bug(s) of 963743: 963234

-- 
963234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963234
963743: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963743
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#963234:

[Sao I Kuan]

Control: block 963743 by -1

Processed:

[Debian Bug Tracking System]

Processing control commands:

> block 963743 by -1
Bug #963743 [wnpp] ITP: benten -- Language server for Common Workflow Language 
documents
963743 was blocked by: 963234
963743 was not blocking any bugs.
Added blocking bug(s) of 963743: 963480

-- 
963480: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963480
963743: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963743
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#963480:

[Sao I Kuan]

Control: block 963743 by -1

Bug#861182: RFS ete

[zhao feng]

> The package at
>
>  https://salsa.debian.org/med-team/python-ete3
>
> builds but is also not finished yet.  I do not remember what had stopped
> me from finalising and uploading.  Please checkout and moreover if you
> talk next time about "ete packaging repositor" provide a link. :-)

Thanks for your information. I have not noticed the existing RFP and
have issued an ITP
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963732.
Should I close the ITP I issued ? I wonder how to turn the RFP into ITP.

I have created a personal repository at
https://salsa.debian.org/zhaofeng-shu33-guest/ete/ and the ci passes
https://salsa.debian.org/zhaofeng-shu33-guest/ete/-/pipelines/152628.
The package has been uploaded to https://mentors.debian.net/package/ete.
I am intending to merge these works into
https://salsa.debian.org/med-team/python-ete3.

Some technical aspect of merging these two repos:
I have found that med-team/python-ete3 repo uses some patches to deal
with the offline testing problems. I think there is a more elegant way
to handle this obstacle.
To summarize the way: using pytest instead of unittest.
For more detail, see
https://lists.debian.org/debian-python/2020/06/msg00035.html.
So I am planning to override med-team/python-ete3 testing rule by
using the one of zhaofeng-shu33-guest/ete/.
For other parts, I think it is not difficult to merge.

Yours
zhaofeng-shu33


On Sat, Jul 4, 2020 at 1:17 AM Andreas Tille  wrote:
>
> On Fri, Jul 03, 2020 at 05:10:32PM +0300, mer...@debian.org wrote:
> > On 2020-07-03 13:50, zhao feng wrote:
> > > Thanks for your help. I can build the package on buster and bullyseye.
> > > Which distribution do you use? I find the version of softwares like
> > > python is quite new.
> >
> > The package fails to build on clean sid chroot. Most likely some Python
> > dependencies are missing from debian/control.
>
> The package at
>
>https://salsa.debian.org/med-team/python-ete3
>
> builds but is also not finished yet.  I do not remember what had stopped
> me from finalising and uploading.  Please checkout and moreover if you
> talk next time about "ete packaging repositor" provide a link. :-)
>
> > By the way, packaging of 'ete3' seems to be ongoing in Debian Med team
> > as well (adding Andreas in CC):
> > https://salsa.debian.org/med-team/python-ete3. I suggest getting in
> > touch with them to keep duplicate efforts minimal.
>
> Definitely.  Thanks for spotting.
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de

Bug#962102: ltunify, something to review

[Geert Stappers]

Hello Anthony,

On Wed, 3 Jun 2020 17:15:45 +0200 Geert Stappers  wrote:
> On Wed, Jun 03, 2020 at 12:40:08PM +0100, Anthony Perkins wrote:
  ...
> > 
> > I believe this might be a good argument for including both. I have done
> > the packaging work already in my personal Gitea repo. I can push this to
> > Salsa for review if that would be useful.
> 
> Yes, make review possible.
> 

Could it be that you are waiting on me?  That I should create a git
repository at Salsa? (I did offer that and the offer still stands)

Anyway: What packaging work can be reviewed?

Goal: ltunify in Debian.


Regards
Geert Stappers
Wannabe uploading sponsor of ltunify

Bug#861182: RFS ete

[Andreas Tille]

Hi,

On Sat, Jul 04, 2020 at 10:48:13PM +0800, zhao feng wrote:
> > The package at
> >
> >  https://salsa.debian.org/med-team/python-ete3
> >
> > builds but is also not finished yet.  I do not remember what had stopped
> > me from finalising and uploading.  Please checkout and moreover if you
> > talk next time about "ete packaging repositor" provide a link. :-)
> 
> Thanks for your information. I have not noticed the existing RFP and
> have issued an ITP
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963732.
> Should I close the ITP I issued ? I wonder how to turn the RFP into ITP.

I do not really mind.  May be merging both bugs is the technical correct
way to go.

> I have created a personal repository at
> https://salsa.debian.org/zhaofeng-shu33-guest/ete/ and the ci passes
> https://salsa.debian.org/zhaofeng-shu33-guest/ete/-/pipelines/152628.
> The package has been uploaded to https://mentors.debian.net/package/ete.

As I said I do not require sponsees to upload to mentors.  The rationale
is that I sometimes want to change things quickly and directly - thus I
always sponsor from salsa repository.

> I am intending to merge these works into
> https://salsa.debian.org/med-team/python-ete3.

Yes, please do so.
 
> Some technical aspect of merging these two repos:
> I have found that med-team/python-ete3 repo uses some patches to deal
> with the offline testing problems. I think there is a more elegant way
> to handle this obstacle.

As I tried to express: Feel free to take over your solution.  There is
no point in sticking to not so good solutions just because they were
invented once.

> To summarize the way: using pytest instead of unittest.
> For more detail, see
> https://lists.debian.org/debian-python/2020/06/msg00035.html.
> So I am planning to override med-team/python-ete3 testing rule by
> using the one of zhaofeng-shu33-guest/ete/.

Yep.  Please go for it! :-)

> For other parts, I think it is not difficult to merge.

Sounds good.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#964258: ITP: mistletoe -- fast, extensible Markdown parser in pure Python

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : python-mistletoe
  Version  : 0.7.2
  Upstream Author  : Mi Yu 
* Url  : https://github.com/miyuchina/mistletoe
* Licenses : Expat
  Programming Lang : Python

 mistletoe is a Markdown parser in pure Python,
 designed to be fast, spec-compliant and fully customizable.
 .
 Apart from being the fastest
 CommonMark-compliant Markdown parser implementation in pure Python,
 mistletoe also supports easy definitions of custom tokens.
 Parsing Markdown into an abstract syntax tree
 also allows us to swap out renderers for different output formats,
 without touching any of the core components.
 .
 CommonMark is a dialect of Markdown with a strict specification.
 .
 Markdown is a lightweight markup language
 with plain-text-formatting syntax.

I plan to maintain this package myself, keeping debianization in following
Git repository:

 https://salsa.debian.org/debian/python-mistletoe.git

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#956033: RFS: idseq-bench [ITP]

[Andreas Tille]

Hi Sao,

On Sat, Jul 04, 2020 at 04:26:36PM +0900, Sao I Kuan wrote:
> Hi,
> 
> I'm looking for a sponsor for the package:
>   * idseq-bench (#956033)
> 
> The package is on:
> https://salsa.debian.org/med-team/idseq-bench
> ...
> Please consider to review and sponsor this. Any kind of suggestions
> are appreciated.

I've build the package and started the executables in /usr/bin with
--help option.  These issue a warning:

unable to import 'smart_open.gcs', disabling that module

Do you know what this means?

Kind regards

  Andreas

-- 
http://fam-tille.de

Processed (with 1 error): your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 909156 ITP: swiftshader -- high-performance CPU-based
Bug #909156 [wnpp] RFP: swiftshader -- high-performance CPU-based 
implementation of OpenGL ES graphics APIs
Changed Bug title to 'ITP: swiftshader -- high-performance CPU-based' from 
'RFP: swiftshader -- high-performance CPU-based implementation of OpenGL ES 
graphics APIs'.
> implementation of OpenGL ES graphics APIs
Unknown command or malformed arguments to command.
> owner 909156 !
Bug #909156 [wnpp] ITP: swiftshader -- high-performance CPU-based
Owner recorded as Yangfl .
> unblock 909156 by 926406
Bug #909156 [wnpp] ITP: swiftshader -- high-performance CPU-based
909156 was blocked by: 926406
909156 was not blocking any bugs.
Removed blocking bug(s) of 909156: 926406
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
909156: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909156
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

[sven]

Package: wnpp
Severity: wishlist
Owner: Sven Hoexter 

* Package name: exfatprogs
  Version : 1.0.3
  Upstream Author : Namjae Jeon 
Hyunchul Lee 
* URL : https://github.com/exfatprogs/exfatprogs
* License : GPL-2
  Programming Lang: C
  Description : tools to create, check and label exFAT filesystems

 Tools to manage extended file allocation table filesystem.
 This package provides tools to create, check and label the
 filesystem. It contains
  - mkfs.exfat to create an exFAT filesystem
  - fsck.exfat to check and repair an exFAT filesystem
  - tune.exfat to print and edit the filesystem label
 The tools included in this package are the exfatprogs
 maintained by Samsung engineers, who provided Linux exFAT
 support. A similar but independent implementation of these
 tools, written by the author of the exfat-fuse implementation,
 are available in the exfat-utils package.


Since people started to ping me about getting this one introduced
I now give in and pick it up. I plan to continue for now the
maintenance of the fuse-exfat and exfat-utils packages.
While fuse-exfat can be coinstalled at any moment exfat-utils and
exfatprogs will for now conflict with each other.
Maybe I later on drop the mkfs.exfat and fsck.exfat links from
the exfat-utils package.

Bug#964266: ITP: golang-github-brentp-irelate: Streaming relation testing of sorted files of intervals

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-github-brentp-irelate
  Version : 0.0~git20180801.1bf7c8f+ds-1
  Upstream Author : Brent Pedersen
* URL : https://github.com/brentp/irelate

* License : Expat
  Programming Lang: Golang
  Description : Streaming relation testing of sorted files of intervals

Description: Streaming relation testing of sorted files of intervals
 Helps to relate (e.g. intersect or by distance) sets of intervals.
 For example, if the nearest gene to a set of ChIP-Seq peaks needs
 to be reported, BEDTools does this extremely well, irelate is an
 attempt to provide an API so that users can write their own tools
 with little effort in go.
 .
 Performance irelate is quite fast, but use PIRelate for parallel
 intersection. It is less flexible than irelate, but skips parsing of
 database intervals for sparse regions in the query.  In addition, it
 has very good (automatic) parallelization.

I shall maintain this package.

Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

[Nicholas D Steeves]

Hi Sven,

s...@stormbind.net writes:

> * Package name: exfatprogs
[snip]
>
> Since people started to ping me about getting this one introduced
> I now give in and pick it up. I plan to continue for now the
> maintenance of the fuse-exfat and exfat-utils packages.
> While fuse-exfat can be coinstalled at any moment exfat-utils and
> exfatprogs will for now conflict with each other.
> Maybe I later on drop the mkfs.exfat and fsck.exfat links from
> the exfat-utils package.

Might /etc/alternatives also be considered for mkfs.exfat and
fsck.exfat?  Also, what about /sbin/mount.exfat?  That one also seems
like a candicate for /etc/alternatives.

Probably tangential: I wonder if this is a case where a virtual package
(where both the Samsung and the exfat-utils Provide exfat-tools or
similar) could be considered?  As you know, I'm primarily interested in
backports, and I wonder if whatever the kernel team does with Wireguard
would be a useful precedent to follow.  eg: if newer kernels Provide:
feature that that was previously wireguard-dkms.  'not sure if that's
over-engineering dependency and feature resolution though ;-)


Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#964273: ITP: golang-github-brentp-vcfgo: Golang library to read, write, manipulate VCF format files

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-github-brentp-vcfgo
  Version : 0.0~git20190824.654ed2e-1
  Upstream Author :  Brent Pedersen
* URL : https://github.com/brentp/vcfgo

* License : Expat
  Programming Lang: Golang
  Description : Golang library to read, write, manipulate VCF format
files

 Package vcfgo implements a Reader and Writer for variant
 call format. It eases reading, filtering modifying VCF's
 even if they are not to spec.
 .
 Status: vcfgo is well-tested, but still in development.
 It tries to tolerate, but report errors; after every
 rdr.Read() call, the caller can check rdr.Error() and
 get feedback on the errors without stopping
 execution unless it is explicitly requested to do so.

I shall maintain this package.

Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

[Sven Hoexter]

On Sat, Jul 04, 2020 at 02:49:15PM -0400, Nicholas D Steeves wrote:

Hi Nicholas,

> > Since people started to ping me about getting this one introduced
> > I now give in and pick it up. I plan to continue for now the
> > maintenance of the fuse-exfat and exfat-utils packages.
> > While fuse-exfat can be coinstalled at any moment exfat-utils and
> > exfatprogs will for now conflict with each other.
> > Maybe I later on drop the mkfs.exfat and fsck.exfat links from
> > the exfat-utils package.
> 
> Might /etc/alternatives also be considered for mkfs.exfat and
> fsck.exfat?
> Also, what about /sbin/mount.exfat?  That one also seems
> like a candicate for /etc/alternatives.

Yes I thought about it, I also thought about dropping the symlinks
similar to the mount.exfat helper issue with fuse-exfat.

Right now I believe we should cater for the general use cases which
probably is someone wanting to mount an exfat filesystem with the
most convenient and fast driver, which is the kernel based one.
So if you have a reason to still want to use the fuse driver you
make an explicit choice. That's when I expect you to be able to
invoke the mount.exfat-fuse helper.

One thing to note is that there is no alternative for the mount.exfat
helper, either it's there or it's not. Michael proposed a thin
wrapper in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963752
but I do not believe that helps the average user. That's why I droped
the symlink from the package.

Now back to the utils situation:
Here we could use alternatives, but I believe for the average user that
will be even more confusing. Luckily upstream of the exfatprogs
made the concious decision to not create a naming colision with the
existing exfat-utils package, so user have a chance to recognise
the different upstream sources. I believe it's more straight forward
to let the user select the implementation he prefers and just make
sure we do not have the naming conflict of the binaries.
The other, longterm more likely option from my point of
view, is to drop the mkfs.exfat and fsck.exfat links, and let the user
invoke exfatfsck and mkexfatfs binary provided by the package.

I do not want to make that change right now, and would prefer to
wait a bit if we see some bugs with the exfatprogs implementation,


> Probably tangential: I wonder if this is a case where a virtual package
> (where both the Samsung and the exfat-utils Provide exfat-tools or
> similar) could be considered?  As you know, I'm primarily interested in
> backports, and I wonder if whatever the kernel team does with Wireguard
> would be a useful precedent to follow.  eg: if newer kernels Provide:
> feature that that was previously wireguard-dkms.  'not sure if that's
> over-engineering dependency and feature resolution though ;-)

I believe the use case here is so narrow that we should keep it as simple
as possible.

Cheers,
Sven