Bug#609038: ITP: biomaj -- a biological databank update and processing tool

[Olivier Sallou]

Package: biomaj
Version: 1.1.0
Severity: wishlist

I want to package the Biomaj tool (http://biomaj.genouest.org) for Debian.
The tool is already on production on several servers worldwide.


-- System Information:
Debian Release: squeeze/sid
  APT prefers lucid-updates
  APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-26-generic (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages biomaj depends on:
ii  ant  1.7.1-4ubuntu1.1Java based build tool like make
ii  debconf  1.5.28ubuntu4   Debian configuration management sy
ii  openjdk-6-jd 6b20-1.9.2-0ubuntu1~10.04.1 OpenJDK Development Kit (JDK)

biomaj recommends no packages.

biomaj suggests no packages.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110105171427.10522.10685.report...@osallou-virtual

[VAC] 11 -> 23 July

[olivier sallou]

Hi,
I won't be available/reachable during this period for package maintenance.
In case of issue, the Debian Med team can manage my packages, thank you for
forwarding the the debian-med mailng list.

Olivier

Bug#756291: (no subject)

[Olivier Sallou]

Subject: ITP: prodigal -- microbial (bacterial and archaeal) gene finding 
program
Package: wnpp
Owner: Olivier Sallou 
Severity: wishlist

* Package name: prodigal
  Version : 2.60
  Upstream Author : Doug Hyatt
* URL : http://prodigal.ornl.gov/
* License : GPL
  Programming Lang: C
  Description : microbial (bacterial and archaeal) gene finding program

 Prodigal (Prokaryotic Dynamic Programming Genefinding Algorithm) is a 
microbial (bacterial and archaeal) gene finding program developed at Oak Ridge 
National Laboratory and the University of Tennessee. Key features of Prodigal 
include:
 .
 Speed: Prodigal is an extremely fast gene recognition tool (written in very 
vanilla C). It can analyze an entire microbial genome in 30 seconds or less.
 .
 Accuracy: Prodigal is a highly accurate gene finder. It correctly locates the 
3' end of every gene in the experimentally verified Ecogene data set (except 
those containing introns). It possesses a very sophisticated ribosomal binding 
site scoring system that enables it to locate the translation initiation site 
with great accuracy (96% of the 5' ends in the Ecogene data set are located 
correctly).
 .
 Specificity: Prodigal's false positive rate compares favorably with other gene 
identification programs, and usually falls under 5%.
 .
 GC-Content Indifferent: Prodigal performs well even in high GC genomes, with 
over a 90% perfect match (5'+3') to the Pseudomonas aeruginosa curated 
annotations.
 .
 Metagenomic Version: Prodigal can run in metagenomic mode and analyze 
sequences even when the organism is unknown.
 .
 Ease of Use: Prodigal can be run in one step on a single genomic sequence or 
on a draft genome containing many sequences. It does not need to be supplied 
with any knowledge of the organism, as it learns all the properties it needs to 
on its own.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140728132249.4925.95345.report...@debiansid.irisa.fr

Packaging of web apps: bower, yeoman...

[olivier sallou]

Hi,
I'd like to know if some developper already packaged web apps using
bower/yeoman. Those tools are more and more popular in web development to
get web related libraries and , with Grunt,
concatenate/minify/obscorate/... used libraries.
The issue is, like npm, maven or other tools, they download resources from
internet to create a local structure of file (js, css, ...) used later on
for minification etc... This is against Debian policy for packaging
(getting files from Internet).

We can of course disable from upstream source the download of resources, to
use local packaged libraries, but this does not give to bower for later
postprocessing the expected directory structure.

So I wonder what others usually do for those apps (if any have already
 packaged such web apps).

Thanks

Olivier

is something wrong with cron.d ?

[Olivier Sallou]

Hi,
I have added a cron task to my package via the package xxx.cron file. (I
am using sid)

However, it never gets executed (not exactly true, it happened to
occur once...)

In my syslog file I can see:
Apr 12 13:04:01 VM-247 /usr/sbin/cron[2999]: (*system*xgrid) RELOAD
(/etc/cron.d/xgrid)
Apr 12 13:10:01 VM-247 /usr/sbin/cron[2999]: (*system*xgrid) RELOAD
(/etc/cron.d/xgrid)
Apr 12 13:17:01 VM-247 /USR/SBIN/CRON[3384]: (root) CMD (   cd / &&
run-parts --report /etc/cron.hourly)
Apr 12 13:20:01 VM-247 /usr/sbin/cron[2999]: (*system*xgrid) RELOAD
(/etc/cron.d/xgrid)
Apr 12 13:24:01 VM-247 /usr/sbin/cron[2999]: (*system*xgrid) RELOAD
(/etc/cron.d/xgrid)
Apr 12 13:29:48 VM-247 /usr/sbin/cron[3478]: (CRON) INFO (pidfile fd = 3)
Apr 12 13:29:48 VM-247 /usr/sbin/cron[3479]: (CRON) STARTUP (fork ok)
Apr 12 13:29:48 VM-247 /usr/sbin/cron[3479]: (CRON) INFO (Skipping
@reboot jobs -- not system startup)
Apr 12 13:46:01 VM-247 /usr/sbin/cron[3479]: (*system*xgrid) RELOAD
(/etc/cron.d/xgrid)

My cron file /etc/cron.d/xgrid is correctly loaded ( I tried to update
it several times to force reload).
I even tried to reboot cron service (last lines).
But it never gets executed

Here is my cron file:
root@VM-247:# more /etc/cron.d/xgrid 
0/5 * * * * root xgrid-graph >/dev/null 2>&1

I added a blank line after my cron definition (or a comment line) as I
have seen there were issues with issues (don(t know if it is still true).

If I execute the command manually it works fine. And anyway, error
should appear in syslog.


could someone tell me if I did something wrong or if it is a cron issue

thanks

Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f86c219.2000...@irisa.fr

Re: is something wrong with cron.d ?

[Olivier Sallou]

STUPID ME!!!
I have spent hours looking for bugs, issues, looking at files not
seeing the syntax error  "0/5"...

Sorry for the noise...

Olivier

Le 4/12/12 1:52 PM, Olivier Sallou a écrit :
> Hi,
> I have added a cron task to my package via the package xxx.cron file. (I
> am using sid)
>
> However, it never gets executed (not exactly true, it happened to
> occur once...)
>
> In my syslog file I can see:
> Apr 12 13:04:01 VM-247 /usr/sbin/cron[2999]: (*system*xgrid) RELOAD
> (/etc/cron.d/xgrid)
> Apr 12 13:10:01 VM-247 /usr/sbin/cron[2999]: (*system*xgrid) RELOAD
> (/etc/cron.d/xgrid)
> Apr 12 13:17:01 VM-247 /USR/SBIN/CRON[3384]: (root) CMD (   cd / &&
> run-parts --report /etc/cron.hourly)
> Apr 12 13:20:01 VM-247 /usr/sbin/cron[2999]: (*system*xgrid) RELOAD
> (/etc/cron.d/xgrid)
> Apr 12 13:24:01 VM-247 /usr/sbin/cron[2999]: (*system*xgrid) RELOAD
> (/etc/cron.d/xgrid)
> Apr 12 13:29:48 VM-247 /usr/sbin/cron[3478]: (CRON) INFO (pidfile fd = 3)
> Apr 12 13:29:48 VM-247 /usr/sbin/cron[3479]: (CRON) STARTUP (fork ok)
> Apr 12 13:29:48 VM-247 /usr/sbin/cron[3479]: (CRON) INFO (Skipping
> @reboot jobs -- not system startup)
> Apr 12 13:46:01 VM-247 /usr/sbin/cron[3479]: (*system*xgrid) RELOAD
> (/etc/cron.d/xgrid)
>
> My cron file /etc/cron.d/xgrid is correctly loaded ( I tried to update
> it several times to force reload).
> I even tried to reboot cron service (last lines).
> But it never gets executed
>
> Here is my cron file:
> root@VM-247:# more /etc/cron.d/xgrid 
> 0/5 * * * * root xgrid-graph >/dev/null 2>&1
>
> I added a blank line after my cron definition (or a comment line) as I
> have seen there were issues with issues (don(t know if it is still true).
>
> If I execute the command manually it works fine. And anyway, error
> should appear in syslog.
>
>
> could someone tell me if I did something wrong or if it is a cron issue
>
> thanks
>
> Olivier
>

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f86c52b.1060...@irisa.fr

debootstrap loading both libept1 AND libept1.4.12, .. and fails!

[olivier sallou]

Hi,
I cannot get debootstrap working anymore in sid since libept update.
There is an open bug (#472704) for this but if someone has an idea of what
is going on to help the debug

A recent upload of libept delivered binary libept1.4.12 instead of libept1
(source release 1.0.6 now).

But when debootstrap runs, it tries to get them both (libept1 from v1.0.5
and libept1.4.12 from v1.0.6).

...
Unpacking libept1 (from .../libept1_1.0.5_amd64.deb) ...
Unpacking libept1.4.12 (from .../libept1.4.12_1.0.6+b1_amd64.deb)
...

This creates an issue because libept1 is not compatible with libapt-pkg4.12.

I simply execute: debootstrap --arch amd64 --keyring /etc/apt/trusted.gpg
--verbose  sid f ftp://ftp.fr.debian.org/debian

But I cannot understand why libept1 is loaded by debootstrap as I cannot
find a package depending on it:

root@debiansid:/tmp# apt-rdepends -r libept1
Reading package lists... Done
Building dependency tree
Reading state information... Done
libept1
  Reverse Depends: goplay (0.5-1)
  Reverse Depends: packagesearch (2.6+b1)
goplay
packagesearch

goplay and packagesearch are not in package list.

Thanks

Olivier


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: debootstrap loading both libept1 AND libept1.4.12, .. and fails!

[olivier sallou]

2012/4/17 olivier sallou 

> Hi,
> I cannot get debootstrap working anymore in sid since libept update.
> There is an open bug (#472704) for this but if someone has an idea of what
> is going on to help the debug
>
> A recent upload of libept delivered binary libept1.4.12 instead of libept1
> (source release 1.0.6 now).
>
> But when debootstrap runs, it tries to get them both (libept1 from v1.0.5
> and libept1.4.12 from v1.0.6).
>
> ...
> Unpacking libept1 (from .../libept1_1.0.5_amd64.deb) ...
> Unpacking libept1.4.12 (from .../libept1.4.12_1.0.6+b1_amd64.deb)
>

I think I understand the issue, both packages are set to Priority:
important,
and deboostrap takes"required" and "important" by default.
Though this creates an issue to debootstrap.

> ...
>
> This creates an issue because libept1 is not compatible with
> libapt-pkg4.12.
>
> I simply execute: debootstrap --arch amd64 --keyring /etc/apt/trusted.gpg
> --verbose  sid f ftp://ftp.fr.debian.org/debian
>
> But I cannot understand why libept1 is loaded by debootstrap as I cannot
> find a package depending on it:
>
> root@debiansid:/tmp# apt-rdepends -r libept1
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> libept1
>   Reverse Depends: goplay (0.5-1)
>   Reverse Depends: packagesearch (2.6+b1)
> goplay
> packagesearch
>
> goplay and packagesearch are not in package list.
>
> Thanks
>
> Olivier
>
>
> --
>
> gpg key id: 4096R/326D8438  (keyring.debian.org)
>
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
>
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: debootstrap loading both libept1 AND libept1.4.12, .. and fails!

[olivier sallou]

2012/4/18 Mike Gabriel 

> Package: libept1.4.12
> Version: 1.0.6.1
> Severity: Important
>
> Hi Oliver, hi Enrico, hi all,
>
>
> On Di 17 Apr 2012 17:29:53 CEST olivier sallou wrote:
>
>  2012/4/17 olivier sallou 
>>
>>  Hi,
>>> I cannot get debootstrap working anymore in sid since libept update.
>>> There is an open bug (#472704) for this but if someone has an idea of
>>> what
>>> is going on to help the debug
>>>
>>> A recent upload of libept delivered binary libept1.4.12 instead of
>>> libept1
>>> (source release 1.0.6 now).
>>>
>>> But when debootstrap runs, it tries to get them both (libept1 from v1.0.5
>>> and libept1.4.12 from v1.0.6).
>>>
>>> ...
>>> Unpacking libept1 (from .../libept1_1.0.5_amd64.deb) ...
>>> Unpacking libept1.4.12 (from .../libept1.4.12_1.0.6+b1_**amd64.deb)
>>>
>>>
>> I think I understand the issue, both packages are set to Priority:
>> important,
>> and deboostrap takes"required" and "important" by default.
>> Though this creates an issue to debootstrap.
>>
>
> same problem here. Chroot creation for my pbuilder environment is not
> possible anymore with a two staged debootstrap.
>

In the meanwhile, if you need to fix the issue, you can add the
"--exclude=libept1" in the DEBOOTSTRAP_OPTS of /etc/debootstrap/config

Olivier


>
> Both packages libept1 and libept1.4.12 get installed by debootstrap.
>
>  $ debootstrap --foreign --arch= \
>   sid sid- ftp://ftp.debian.org/debian
>  $ cd sid-
>  $ chroot .
>  $ /debootstrap/debootstrap --second-stage
>
> libept1 depends on libapt-pkg4.10. However, libapt-pkg4.10 is not
> available in SID anymore, so libept1 fails to install during debootstrap.
>
> 
> dpkg: dependency problems prevent configuration of libept1:
>  libept1 depends on libapt-pkg4.10; however:
>  Package libapt-pkg4.10 is not installed.
> dpkg: error processing libept1 (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  libept1
> 
>
> 
> root@japsand:/debootstrap# apt-cache show libapt-pkg4.10
> N: Can't select versions from package 'libapt-pkg4.10' as it is purely
> virtual
> N: No packages found
> root@japsand:/debootstrap# apt-cache show libapt-pkg^C
> root@japsand:/debootstrap# apt-get install libapt-pkg4.10
> Reading package lists... Done
> Building dependency tree... Done
> Package libapt-pkg4.10 is not available, but is referred to by another
> package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> E: Package 'libapt-pkg4.10' has no installation candidate
> root@japsand:/debootstrap#
> 
>
> Any idea how to fix this / work around this???
>
> Thanks,
> Mike
>
> --
>
> DAS-NETZWERKTEAM
> mike gabriel, dorfstr. 27, 24245 barmissen
> fon: +49 (4302) 281418, fax: +49 (4302) 281419
>
> GnuPG Key ID 0xB588399B
> mail: mike.gabriel@das-netzwerkteam.**de,
> http://das-netzwerkteam.de
>
> freeBusy:
> https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-**
> netzwerkteam.de.xfb<https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb>
>



-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#674265: ITP: biojava3 -- Java API to develop tools for bioinformatics research rewrote from biojava1

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: biojava3
  Version : 3.0.4
  Upstream Author : BioJava team
* URL : http://www.biojava.org/
* License : LGPL
  Programming Lang: Java
  Description : Java API to develop tools for bioinformatics research 
rewrote from biojava1

 BioJava is an open-source project dedicated to providing a Java framework
 for processing biological data. It includes objects for manipulating
 sequences, file parsers, DAS client and server support, access to BioSQL
 and Ensembl databases, and powerful analysis and statistical routines
 including a dynamic programming toolkit.
 .
 BioJava is provided by a vibrant community which meets annually at
 the Bioinformatics Open Source Conference (BOSC) that traditionally
 accompanies the Intelligent Systems in Molecular Biology (ISMB)
 meeting. Much like BioPerl, the employment of this library is valuable
 for everybody active in the field because of the many tricks of the
 trade one learns just by communicating on the mailing list.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120524073403.6935.83155.report...@debiansid.genouest.org

Bug#674269: ITP: libforester-java -- library for phylogenomics and evolutionary biology research

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: forester
  Version : 0.955
* URL : http://code.google.com/p/forester/
* License : LGPL
  Programming Lang: Java
  Description : library  for phylogenomics and evolutionary biology research

forester is a collection of open source libraries of Java software for 
phylogenomics
 and evolutionary biology research. For example, the tree viewer Archaeopteryx 
is based on forester.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120524074747.9147.25806.report...@debiansid.genouest.org

apache 2.4 transition bugs

[Olivier Sallou]

Hi,
as Apache 2.4 transition has been delayed, should not created bugs, set
with Important severity be lowered ?
or closed and reopen when transition will occur?

I have several packages impacted.

Thanks


Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fbe5c61.3040...@irisa.fr

Re: Packaging on GitHub ?

[olivier sallou]

Le 27 mai 2012 03:12, "Jon Bernard"  a écrit :
>
> * Charles Plessy  wrote:
> > Hello everybody,
> >
> > for one of the packages maintained by the pkg-eucalyptus team
(euca2ools), the
> > upstream source moved to GitHub, and we would like to try to maintain
the
> > Debian package there as well.
> >
> > I see that there is already a Debian account on GitHub
> > (https://github.com/debian), currently empty.  Does it belong to a
Developer ?
> > Would it be availble to maintain the euca2ools package in ?
> >
> > I never tried GitHub before.  I know it is not Free.  The point
maintaining a
> > Debian package on GitHub would be to easily make pull requests to
Upstream.  Is
> > it something that would be doable from external repositories, for
instance
> > making a pull request to GitHub from Alioth ?  (I mean, the Pull Request
> > function of GitHub, not sending an email Upstream saying in plain
English that
> > they can pull from Alioth).
>
> I believe a Github pull-request must reference a commit within Github
itself.
> You could still file an issue linking to an external repository, but I
suspect
> they're encouraging you to use Github for packaging so they can leverage
all of
> the utilities that Github provides. You could always use Alioth as the
primary
> repository and keep an updated mirror on Github just for this sort of
thing.
>
Github tools work with local repo only. Keeping an updated mirror is not a
good method for me, it is a painful task and you are never sure of the
status

By the way, you can t use Debian repo to put several repo. a github repo
refers to a single git repo.

For info, there is a very nice github like free tool named gitlab , but it
I a software, not a service.
Olivier
> --
> Jon
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive: http://lists.debian.org/20120527011140.GB32538@quintessa
>
 Le 27 mai 2012 03:12, "Jon Bernard"  a écrit :

Bug#678373: ITP: logol -- Pattern matching tool for biological sequences

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: logol
  Version : 1.5.0
  Upstream Author : Olivier Sallou 
* URL : http://logol.genouest.org
* License : CeCILL
  Programming Lang: Java, Prolog
  Description : Pattern matching tool for biological sequences

Logol is a pattern matching tool using the logol language.
It searches with a specific grammar a pattern in small
or large sequence (dna,rna,protein). It provides complete
result matching with the original grammar in the results.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120621084050.16957.7348.report...@debiansid.genouest.org

Bug#683291: ITP: soapdenovo -- short-read assembly method that can build a de novo draft assembly for the human-sized genomes

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: soapdenovo
  Version : 1.0.5
  Upstream Author : BGI-Shenzhen
* URL : http://soap.genomics.org.cn/soapdenovo.html
* License : GPL3+
  Programming Lang: C
  Description : short-read assembly method that can build a de novo draft 
assembly for the human-sized genomes

SOAPdenovo is a novel short-read assembly method that can build a de novo draft 
assembly for the human-sized genomes.
The program is specially designed to assemble Illumina GA short reads.
It creates new opportunities for building reference sequences and carrying out 
accurate analyses of unexplored genomes in a cost effective way.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120730150253.31191.64978.report...@debiansid.genouest.org

Re: Enabling uscan to simply remove files from upstream source

[olivier sallou]

2012/8/21 Andreas Tille 

> Hi,
>
> third summary of the proposal
>
>  1. The new field Files-Excluded in debian/copyright contains a space
> separated list of globs (as used by find and for specifying file
> lists in machine readable debian/control files). The deletion
> process will loop over every expression
>
>   rm -rf ${MAIN_SOURCE_DIR}/
>
> An example copyright file would look like this:
>
> Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Source: http://susy.oddbird.net/
>   Repackaged, excluding non-DFSG licensed fonts and source-less
>   JavaScript
> Files-Excluded:
>   docs/source/fonts/*
>   docs/source/javascripts/jquery-1.7.1.min.js
>   docs/source/javascripts/modernizr-2.5.3.min.js
>
>  2. If files matching are contained in the source tarball this will
> be repackaged except if the option --no-exclusion is given at
> uscan command line or if USCAN_NO_EXCLUSION is set in
> /etc/devscripts.conf or ~/.devscripts.
>
>  3. If the tarball did not contained any of the globs in
> debian/copyright::Files-Excluded it should be left untouched
> (except if the repackaging is needed because of compression method
> anyway if the user forces --repack).
>

Just a remark, it would be nice in this case to get a warning/log that
some/all glob do not match to track changes in upstream tarballs (exclusion
in previous release, then not needed anymore).

Olivier


>  4. In case something was removed the version string will be appended by
> '+dfsg' to express the fact that the content of the original source
> was changed.
>
> This discussion brought up additional new wishlist features for uscan:
>
>  a) Configurable option when repacking (this is somehow related to
> the suggestion above but I would like to split up this to a
> different task).
>
>  b) Uscan should be enabled to download VCS repositories (and once
> it does deletion of files should be possible according to the same
> method above (this is an interesting feature in principle but once
> uscan is able to delete files it can do it for any download method).
>
>  c) The suggested repackaging method was requested for non-uscan
> based downloads (for instance from VCS) which might have an
> influence for the final implementation as a separate tool which
> could simply called by uscan (and others).
>
>  d) Enable confirguration of compression method.  I'd consider this
> an unrelated feature which also could be useful for --repack.
> I admit once we are repackaging anyway it might be reasonable to
> be able to influence the compression method but I also would like
> to split this up to a different task.
>
> Regarding the implementation there was some uncertainity about the
> actual Perl module to use.  In the attached example script I decided to
> stick to Dpkg::Control and left the code for Parse::DebControl as a
> comment which could pretty easily could replace the other parser.  The
> code works for me however, there might be some remaining empty
> directories which I'm tempted to delete these as well via an "educated"
>
>find tmp -type d -empty -delete
>
> which means I would care for deleting only those directories that became
> empty by the previous removal process and not those directories which
> were originally empty in the tarball.  On the other hand we might simply
> go with those empty dirs that finally do not harm.
>
> Any further hints / remarks?
>
> Kind regards
>
>   Andreas.
>
> --
> http://fam-tille.de
>



-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#686077: ITP: libsnappy1.0.3-java -- Fast Java compressor/decompressor, port of Snappy

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: libsnappy1.0.3-java
  Version : 1.0.3-rc3
  Upstream Author : Xerial.org
* URL : 
https://code.google.com/p/snappy-java/downloads/list?can=4&q=&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount
* License : Apache-2.0
  Programming Lang: Java
  Description : Fast Java compressor/decompressor, port of Snappy

 Java port of Snappy, a fast compresser/decompresser written in C++,
 originally developed by Google. 
 .
 Snappy's main target is very high-speed compression/decompression with
 reasonable compression size. So the compression ratio of snappy-java is
 modest and about the same as LZF (ranging 20%-100% according to the
 dataset). 
 .
 This version of the Java library is not the latest upstream version
 but it has an ABI which is used by picard-tools package and was finally
 packaged exactly for the purpose to support ppicard-tools.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120828104330.28493.95641.report...@debiansid.genouest.org

Re: On accepting pre-generated doc from upstream

[olivier sallou]

2013/6/7 Lisandro Damián Nicanor Pérez Meyer 

> Hi everyone. First of all, I'm cross-posting this between legal and devel
> because I really don't know to which of them belongs (or maybe it does in
> both).
>
> The issue is this: Qt 5 has grown so large (850+MB unpacked in the single-
> source tarball, will continue growing) that upstream also provides it as
> submodules. 15 of them in 5.0.2.
>
> Of course, in terms of maintainance, we have opted for the submodules
> choice.
>
> Building the full doc could be done in two ways:
>
> - Using the full source tarball. Saddly this means having to compile most
> of
> it in order to get the tools for building the doc, or hacking far too much
> the
> build system to do something else.
>
> - Build each submodule's doc.
>
> While the second option seems the clear winner, there is a gotcha: you need
> packages 1 and 2 built and in the archive to build the documentation.
> Including their documentation. Packages 3 to 15 should not present further
> problems.
>
> So this can be solved by packaging 1 and 2 without docs and pushing them to
> the archive. Then, once 1 and 2 have been built on *every* arch, repackage
> 1
> and 2 with the documentation and upload them.
>
> This means that we need to bootstrap the packages. And we may need to do it
> for every major release (5.1, 5.2,...), although it's not confirmed.
>
> As a possible workaround, upstream has suggested to provide the
> documentation
> already generated (could be for the submodules and/or the full doc, this
> has
> not been discussed yet). My first reaction has been to think that this will
> not be allowed in Debian, but giving it some more thought,:
>
> - We do have the source code for generating it (preferred form of
> modification).
>
> - We can build it, but it requires lot of work... and avoid FTBFSs while
> bootstrapping ;)
>
> So, could we accept pre-generated documentation in this case?
>


For me , delivering the prebuilt doc is not an issue as long as we have the
documentation source (latex to generate pdf for example).
We should avoid too much burden/tricks in package build for documentation
if we can rely upon it while still being policy compliant (source given).

Though packager should at least build the doc himself, locally to be sure
doc can indeed be generated.

Olivier



>
> Kinds regards, and thanks in advance for your time, Lisandro.
>
> --
> 14: Para acceder y navegar en internet
> * Debe tener conexion a Internet
> Damian Nadales
>
> http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>



-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

overriding udev rules

[olivier sallou]

hi,
I need for a package to override some udev standard rules.

If I put an identical rule name in /etc/udev/rules.d, I know it overrides
the one in /lib/udev/rules.d


However, lintian raises an error if I put an udev rule in /etc instead of
/lib.
And if I try to put the file in /lib, it fails at install because the file
is owned by udev package.

This particular package is for use in virtual machines creation where
package removes default network persistence.

Is there an other way to override udev rules in package or should I simply
override the lintian error message?

Thanks

Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: overriding udev rules

[olivier sallou]

2013/8/20 Michael Biebl 

> Am 20.08.2013 10:39, schrieb olivier sallou:
> > hi,
> > I need for a package to override some udev standard rules.
> >
> > If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> > the one in /lib/udev/rules.d
> >
> >
> > However, lintian raises an error if I put an udev rule in /etc instead of
> > /lib.
> > And if I try to put the file in /lib, it fails at install because the
> file
> > is owned by udev package.
> >
> > This particular package is for use in virtual machines creation where
> > package removes default network persistence.
>
> Could you elobarate why you need that?
> The persistent network interface naming rules are already skipped if
> udev is run within a virtual machine.
> Might be better to just fix udev if it doesn't work in your case.
> For that, it would be good to know more about your problem / use case.
>
ok,
I am packaging a package for OpenNebula that is to be installed on virtual
machine images.
It does many setup at startup.
Among other things, in upstream packages, it replaces 2 udev rules:
75-cd-aliases-generator.rules and 75-persistent-net-generator.rules.
The new rules does nothing, it just expects to skip the existing one.

I did not know that udev skipped (at least) persistent-net in virtual
machines so I did not try without those replacement rules (how does it know
it is a virtual machine?).


Olivier

>
> Michael
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: overriding udev rules

[olivier sallou]

2013/8/20 olivier sallou 

>
>
>
> 2013/8/20 Michael Biebl 
>
>> Am 20.08.2013 10:39, schrieb olivier sallou:
>> > hi,
>> > I need for a package to override some udev standard rules.
>> >
>> > If I put an identical rule name in /etc/udev/rules.d, I know it
>> overrides
>> > the one in /lib/udev/rules.d
>> >
>> >
>> > However, lintian raises an error if I put an udev rule in /etc instead
>> of
>> > /lib.
>> > And if I try to put the file in /lib, it fails at install because the
>> file
>> > is owned by udev package.
>> >
>> > This particular package is for use in virtual machines creation where
>> > package removes default network persistence.
>>
>> Could you elobarate why you need that?
>> The persistent network interface naming rules are already skipped if
>> udev is run within a virtual machine.
>> Might be better to just fix udev if it doesn't work in your case.
>> For that, it would be good to know more about your problem / use case.
>>
> ok,
> I am packaging a package for OpenNebula that is to be installed on virtual
> machine images.
> It does many setup at startup.
> Among other things, in upstream packages, it replaces 2 udev rules:
> 75-cd-aliases-generator.rules and 75-persistent-net-generator.rules.
>

As additional information, this is needed when you clone, reuse some
virtual machine.


> The new rules does nothing, it just expects to skip the existing one.
>
> I did not know that udev skipped (at least) persistent-net in virtual
> machines so I did not try without those replacement rules (how does it know
> it is a virtual machine?).
>
>
> Olivier
>
>>
>> Michael
>>
>>
>> --
>> Why is it that all of the instruments seeking intelligent life in the
>> universe are pointed away from Earth?
>>
>>
>
>
> --
>
> gpg key id: 4096R/326D8438  (keyring.debian.org)
>
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Fwd: Re: overriding udev rules

[olivier sallou]

Ccing the list
-- Message transféré --
De : "olivier sallou" 
Date : 20 août 2013 22:27
Objet : Re: overriding udev rules
À : "Thomas Goirand" 

Le 20 août 2013 22:18, "Thomas Goirand"  a écrit :

>
> On 08/20/2013 07:02 PM, olivier sallou wrote:
> > I did not know that udev skipped (at least) persistent-net in virtual
> > machines so I did not try without those replacement rules (how does it
> > know it is a virtual machine?).
>
> Oh, missed that part! I also would be happy to know how it does it.
With a quick look at script it seems to skip the rule for a set of MAC
address masks commonly used in different systems (KVM VMWARE..) but this
does not fit for all nor users custom config.
>
> Thomas
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive: http://lists.debian.org/5213cace.5000...@debian.org
>

Re: overriding udev rules

[olivier sallou]

2013/8/21 Peter Palfrader 

> On Tue, 20 Aug 2013, Thomas Goirand wrote:
>
> > I'd be happy to find a correct and clean way to do this, because I also
> > need to do it, and it seems to be a fairly common use case. I currently
> > only delete the 75-persistent-net-generator.rules file (which I know is
> > the wrong way to do it as it wont survive upgrades, though I currently
> > don't know how to do it cleanly, so I have fallen back to that).
>
> touch /etc/udev/rules.d/75-persistent-net-generator.rules
>
> yeap, as a user, but it is said that packages must not write rules in
/etc/udev/rules.d



>
> http://anonscm.debian.org/gitweb/?p=mirror/dsa-misc.git;a=blob;f=scripts/VM-installs/ganeti-bytemark;hb=HEAD#l116
>
> HTH,
> Cheers,
> weasel
> --
>|  .''`.   ** Debian **
>   Peter Palfrader  | : :' :  The  universal
>  http://www.palfrader.org/ | `. `'  Operating System
>|   `-http://www.debian.org/
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/20130821072010.gl1...@anguilla.noreply.org
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: overriding udev rules

[olivier sallou]

I think I gonna simply skip the udev rules overriding, it will be up to the
user to do the cleaning if he wants to do cloning etc... as done in
cloud-init package, waiting for easier udev management from package side.

Thanks to all for your advises.


quoting previous...

-- 
>
> gpg key id: 4096R/326D8438  (keyring.debian.org)
>
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#644136: ITP: ruby-text -- collection of text match and analysis algorithms

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: ruby-text
  Version : 1.1.2
  Upstream Author : Paul Battley, Michael Neumann, Tim Fletcher
* URL : https://rubygems.org/gems/Text
* License : GPL
  Programming Lang: Ruby
  Description : collection of text match and analysis algorithms

Library for match and analysis on text strings. Contains levenshtein
 distance calculation, Porter Stemming and others.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111003073747.4361.29778.report...@debiansid.genouest.org

Bug#644137: ITP: ruby-cassiopee -- provide methods to search exact match or approximate matches with Hamming or edit distance

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: ruby-cassiopee
  Version : 0.1.8
  Upstream Author : Olivier Sallou 
* URL : https://rubygems.org/gems/cassiopee
* License : GPL
  Programming Lang: Ruby
  Description : provide methods to search exact match or approximate 
matches with  Hamming or edit distance

Library to search an exact or approximate word (hamming or edit distance) in a 
string.
Support index cache with incremental update for later searches



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111003074409.4386.41013.report...@debiansid.genouest.org

Build error form Ubuntu regarding xz compression

[olivier sallou]

Hi,
I received an email error from Ubuntu regarding build of a package
(extracted from debian):

Rejected:
Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression.
Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression.


Package indeed uses xz compression, but do you know what I should put
in package for this on debian side?

Should I add in debian control a pre-depends on dpkg as said in message?

I think that someone else already the issue...


Thanks


Olivier


-- 

gpg key id: 4096R/326D8438  (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: Build error form Ubuntu regarding xz compression

[olivier sallou]

Thanks for clarification

2011/10/19 Colin Watson 

> On Wed, Oct 19, 2011 at 02:09:47PM +0200, olivier sallou wrote:
> > I received an email error from Ubuntu regarding build of a package
> > (extracted from debian):
>
> I'm sorry you received this error; this is a Launchpad bug
> (https://bugs.launchpad.net/launchpad/+bug/876594).  We obviously don't
> want to spam Debian developers with Ubuntu upload errors.
>
> > Rejected:
> > Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression.
> > Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression.
> >
> >
> > Package indeed uses xz compression, but do you know what I should put
> > in package for this on debian side?
> >
> > Should I add in debian control a pre-depends on dpkg as said in message?
>
> Didier has already answered this.  Making such a change is indeed
> harmless in Debian.
>
> I would also add that I've been fixing all these in Ubuntu as we go
> along (in changes that we'll be able to discard after Ubuntu 12.04 LTS)
> on the grounds that it's basically our fault for not having managed to
> get dpkg 1.15.6 into our last LTS release and thus we should cope with
> the fallout; so while I certainly wouldn't say no if Debian developers
> want to add the appropriate Pre-Depends, we'll cope if you don't.
>
> Thanks,
>
> --
> Colin Watson   [cjwat...@ubuntu.com]
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/20111019125056.ga7...@riva.dynamic.greenend.org.uk
>
>


-- 

gpg key id: 4096R/326D8438  (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#647416: ITP: libbio-chado-schema-perl -- object-relational mapping layer for use with the GMOD Chado database schema

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: libbio-chado-schema-perl
  Version : 0.09010
  Upstream Author : Robert Bruels 
* URL : 
http://search.cpan.org/~rbuels/Bio-Chado-Schema/lib/Bio/Chado/Schema.pm
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : object-relational mapping layer for use with the GMOD Chado 
database schema

This is a standard object-relational mapping layer for use with the GMOD Chado 
database schema.
This layer is implemented with DBIx::Class, generated with the help of the very 
fine DBIx::Class::Schema::Loader module.
Chado is an open-source modular database schema for biological data. It is 
divided into several notional "modules", which are reflected in the namespace 
organization of this package. Note that modules in the Chado context refers to 
sets of tables, they are not modules in the Perl sense.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2002131738.29034.70434.report...@debiansid.genouest.org

Bug#647417: ITP: libdbix-class-tree-nestedset-perl -- Manage trees of data using the nested set model

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: libdbix-class-tree-nestedset-perl
  Version : 0.10
  Upstream Author : Ian Docherty 
* URL : 
http://search.cpan.org/~icydee/DBIx-Class-Tree-NestedSet-0.10/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Manage trees of data using the nested set model

Manage trees of data using the nested set model



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2002134124.29178.39101.report...@debiansid.genouest.org

Re: Want to become a DM and co-maintainer

[olivier sallou]

2011/11/12 Svante Signell 

> Hi,
>
> Where/how to apply to become a co-maintainer and a maintainer? The
> packages I'm interested into start with are: gnuradio and octave.
> Additionally, I have not found any package for USRP yet.
>

At first, you will have to maintain package via a sponsor or a team. After
some time, according to your sponsor, you will be able to ask to be a DM so
that you are able to maintain by yourself the package.
Once ready for being a DM, you can go here:

http://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_Maintainer

>
> Thanks!
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/1321127664.6311.24.camel@x60
>
>


-- 

gpg key id: 4096R/326D8438  (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#652031: ITP: clustalo -- Clustal Omega is the latest addition to the Clustal family

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: clustalo
  Version : 1.0.3
  Upstream Author : clust...@ucd.ie
* URL : http://www.clustal.org/omega/
* License : GPL
  Programming Lang: C
  Description : Clustal Omega is the latest addition to the Clustal family

Clustal Omega offers a significant increase in scalability over previous 
clustal versions,
 allowing hundreds of thousands of sequences to be aligned in only a few hours.
It will also make use of multiple processors, where present.
In addition, the quality of alignments is superior to previous versions, as 
measured by a range of popular benchmarks.
Please note that Clustal Omega is currently a command line-only tool, and is 
only suitable for aligning protein sequences, not DNA or RNA.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111214101532.7097.54686.report...@debiansid.genouest.org

Bug#654603: ITP: gassst -- Global Alignment Short Sequence Search Tool

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: gassst
  Version : 1.28
  Upstream Author : Dominique Lavanier 
* URL : http://www.irisa.fr/symbiose/projects/gassst/
* License : CeCILL v2
  Programming Lang: C++
  Description : Global Alignment Short Sequence Search Tool

GASSST finds global alignments of short DNA sequences against large DNA banks.
It also provides a converter to SAM format.
The program takes a bank file and a collection of very short DNA sequences as 
input
 and outputs a global alignement of the collection against the bank.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120104145152.22002.74049.report...@debiansid.genouest.org

Bug#657184: ITP: j2f -- Java Application Programming Interfaces (APIs) to numerical libraries originally written in Fortran

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: j2f
  Version : 0.8.1
  Upstream Author : Keith Seymour (seym...@cs.utk.edu)
* URL : http://sourceforge.net/projects/f2j/
* License : GPL
  Programming Lang: C
  Description : Java Application Programming Interfaces (APIs) to numerical 
libraries originally written in Fortran

The goal of the Fortran-to-Java project is to provide Java Application 
Programming Interfaces (APIs) to numerical
libraries originally written in Fortran (particularly BLAS and LAPACK).
The program generates a Java library containing object wrappers.
This package is needed for package beast-mcmc.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120124171931.9549.63032.report...@debiansid.genouest.org

nm.debian.org web site not responding

[olivier sallou]

Hi,
the web site

https://nm.debian.org/nmlist.php

has a forbidden access error for a few days. Do you know who we should
contact ?

Thanks

Olivier

-- 

gpg key id: 4096R/326D8438  (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

A few questions from a new DD

[olivier sallou]

Hi,
I got my DD status a few days ago. I have 2 questions:

1) How can I send email using my @debian.org as origin ?
2) I cannot login to debian servers (tried people.debian.org), I have a
permission denied. My SSH key is not yet set, so I cannot login using it. I
expected to be prompted for password, but it doesn't. Are debian servers
SSH key based only?
Here are ssh logs:
.
debug1: Host 'people.debian.org' is known and matches the RSA host key.
debug1: Found key in /Users/osallou/.ssh/known_hosts:55
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/osallou/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/osallou/.ssh/identity
debug1: Trying private key: /Users/osallou/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).


Thanks

Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: A few questions from a new DD

[olivier sallou]

2012/2/29 Jonathan Wiltshire 

> On 2012-02-29 09:26, olivier sallou wrote:
>
>> Hi,
>> I got my DD status a few days ago. I have 2 questions:
>>
>> 1) How can I send email using my @debian.org [1] as origin ?
>>
>
> Just set your From header accordingly.
>
>  2) I cannot login to debian servers (tried people.debian.org [2]), I
>>
>> have a permission denied. My SSH key is not yet set, so I cannot login
>> using it. I expected to be prompted for password, but it doesn't. Are
>> debian servers SSH key based only?
>>
>
> Yes, they are. You'll have to wait for your key to be pushed to the
> machines you're interested in.
> (You can log in to db.debian.org in the meantime)
>

I already logged to web interface to update my profile.
I do not see however any SSH key attribute in the web interface, did I miss
something?. I know that it can be done via the GPG gateway, sending an
email.

>
> --
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
>
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
>
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-devel-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/**79a3a6a93f413002424a503df3e6d5**
> 1...@hogwarts.powdarrmonkey.net<http://lists.debian.org/79a3a6a93f413002424a503df3e6d...@hogwarts.powdarrmonkey.net>
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: A few questions from a new DD

[olivier sallou]

2012/2/29 Andreas Tille 

> Hi,
>
> On Wed, Feb 29, 2012 at 10:56:28AM +0100, Alexander Reichle-Schmehl wrote:
> > > I already logged to web interface to update my profile.
> > > I do not see however any SSH key attribute in the web interface, did I
> > > miss something?. I know that it can be done via the GPG gateway,
> sending
> > > an email.
> >
> > IIRC you'l have to use the mail gateway to set your ssh key.  See
> > http://db.debian.org/doc-mail.html for details.
>
> Which boils down to
>
>  cat ~/.ssh/.pub | gpg --clearsign > send_this_to_changes
>  echo "cat send_this_to_changes | mailx -s "Please change SSH key"
> chan...@db.debian.org"
>
>
I could fix the problem using the mail gateway, I was just surprised that
it does not appear in web interface, and I could not see in Debian wiki
that SSH key is mandatory for login. Anyway everything is fine now.

Thanks


> Hope this helps
>
>  Andreas.
>
> --
> http://fam-tille.de
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20120229124115.ge11...@an3as.eu
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: Bug#662513: RM: emboss/6.3.1-6

[Olivier Sallou]

Le 3/5/12 1:25 PM, Charles Plessy a écrit :
> Le Mon, Mar 05, 2012 at 11:51:35AM +, Tim Booth a écrit :
>> I'll be up at the EBI in a couple of weeks.  Is there anything I can do
>> to try and persuade them to grant an acceptable license or has this
>> already been tried?  EMBOSS is a software package that I still consider
>> to be very important, even though development is currently stalled due
>> to lack of funding.
> Hi Tim,
>
> The non-free file is a Uniprot record in the test suite, so the EMBOSS
> developers can not re-license it.  Actually, I am wondering if, in isolation
> from the whole UniProt database, a single record is copyrightable, since it is
> only the reproduction of facts.  In that case, we could simply ignore its
> license.  I have asked Debian's FTP team their opinion on that matter.
>
>   http://lists.debian.org/debian-med/2012/03/msg00010.html
>
> Among the other options, there is the removal of the file from the package.
> This is something I dislike, as it is extra work for no extra freedom.
>
> The conceptual problem is that the purpose of that file is to test that EMBOSS
> properly parses UniProt records, so it is obviously impossible to replace.
>
> The other problem is that other packages, for instance BioPerl, also contain
> UniProt records in their test suite.  This is a nightmare that I find very
> demotivating.
>
> Please give my best regards to the EMBOSS developers.  I think that the best
> they can do is to lobby UniProt to release test data in the public domain,
> or to relicense their whole database under a free license.  All illogical
> it may sound, we need the permission to modify the protein sequences against
> scientific evidence, even if we do not plan to ever do it.
>
> By the way: one of the reasons I have not updated emboss is also that I am
> stuck with other packaging works, in particular libsnappy-java where I have
> reached my level of incompetence (http://bugs.debian.org/636181).  I have
> already wasted some time from Andreas and Java developers, but I think that 
> the
> only way out would be that somebody takes the work over entirely.  We need
> libsnappy-java to update the picard-tools.
Regarding libsnappy, what is your problem ? When I have time I may have
a look if you want to.
Code is in SVN of Java team?


Olivier
> Lastly, the request I made was to remove emboss from Testing, but this is not 
> a
> request for removal from Debian, and I really aim at shipping an up-to-date
> EMBOSS in Wheezy.
>
> Cheers,
>

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f54b583.8040...@irisa.fr

Bug#665341: ITP: libjlapack-java -- LAPACK numerical subroutines translated from Fortran to Java

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: libjlapack-java
  Version : 0.8
  Upstream Author : Keith Seymour
* URL : http://icl.cs.utk.edu/f2j/
* License : BSD
  Programming Lang: Fortran, Java
  Description : LAPACK numerical subroutines translated from Fortran to Java

The JLAPACK project provides the LAPACK numerical subroutines translated from 
their subset Fortran 
 77 source into class files, executable by the Java Virtual Machine (JVM) and 
suitable for use by Java programmers.
This makes it possible for Java applications or applets, distributed on the 
World Wide Web (WWW) to use
 established legacy numerical code that was originally written in Fortran.
The translation is accomplished using a special purpose Fortran-to-Java 
(source-to-source) compiler.
The LAPACK API will be considerably simplified to take advantage of Java’s 
object-oriented design.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120323083028.29933.15074.report...@debiansid.genouest.org

Bug#665343: ITP: libnetlib-java -- collection of mission-critical software components for linear algebra system translated from Fortran to Java

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: libnetlib-java
  Version : 0.9.3
  Upstream Author : Sam Halliday 
* URL : http://code.google.com/p/netlib-java
* License : BSD
  Programming Lang: Fortran, Java
  Description : collection of mission-critical software components for 
linear algebra system translated from Fortran to Java

Netlib is a collection of mission-critical software components for linear 
algebra systems (i.e. working with vectors or matrices).
Netlib libraries are written in C, Fortran or optimised assembly code. This 
Java translation has been provided by the F2J project
 but it does not take advantage of optimised system libraries.

This library provides a wrapper layer that gives Java programmers access to a 
common API which can be configured to use either
 the pure Java or natively optimised implementations of BLAS, LAPACK and ARPACK 
such as:
Intel's Math Kernel Library
AMD's Core Math Libary
Apple's vecLib Framework
the popular open source ATLAS.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120323083749.29993.50156.report...@debiansid.genouest.org

Re: Discarding uploaded binary packages

[olivier sallou]

Le 16 oct. 2012 04:59, "Michael Gilbert"  a écrit :
>
> I know this subject has been discussed on and off in the past, but
> there's new evidence that it's simply the right thing to do.
>
> Due to changes in upstream's build system, isc-dhcp recently started
> including build system paths in dhclient's search path.  This got a
> security identifier, and we've fixed it, but really the only
> architecture affected was the one I built and uploaded.  All of the
> packages built on the buildds were not since the PATH was something in
> /build vs. a home dir.  Also, Ubuntu was not affected since all of
> their packages go through their buildds.  Details in:
> http://bugs.debian.org/690532
>
> Anyway, all of these build system path sanitization issues can be
> eliminated by using the buildds for all architectures, since paths
> will start with at least /build that requires root-level action to
> exist on users' systems.
>
> So, are we ready to do this?
+1  ;-)

I agree with this. We face some cases where delivered binary have issues
related to build context. Though most should be discovered by maintainer
testing before upload, it would be more valid with a complete rebuild.

This is my opinion but I admit I have not followed previous discussions on
the subject
>
> Best wishes,
> Mike
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive:
http://lists.debian.org/CANTw=MNag1=MZG3GiUCyGXsVRBjDKc62_WNLYHP5juXo=_4...@mail.gmail.com
>

Bug#700859: ITP: mobyle-tutorials -- Tutorial descriptors for the mobyle package

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: mobyle-tutorials
  Version : 1.5.0
  Upstream Author : Mobyle team
* URL : ftp://ftp.pasteur.fr/pub/GenSoft/projects/mobyle/
* License : LGPL-2+
  Programming Lang: XML
  Description : Tutorial descriptors for the mobyle package

Mobyle can deploy tutorials for programs just like other programs and viewers. 
This package contains base tutorials on a few tools.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130218145514.11131.48455.report...@debiansid.genouest.org

Re: Generators for debian/* files?

[olivier sallou]

dh-make-perl indeed for Perl CPAN packages.

dh-make for base packages...

Olivier


2013/4/5 Thomas Koch 

> Hi,
>
> debian-java has the tool "mh_make" that generates debian packages from
> maven
> projects. There's some java code in there that produces debian/* files:
> rules,
> copyright, watch, control, orig-tar.sh, doc-base.api, doc.install and of
> course source/format and compat.
>
> This java code should be replaces with something in perl/python/non-JVM. Is
> there already some logic/templates in Debian that I could build on?
>
> Regards,
>
> Thomas Koch, http://www.koch.ro
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/201304051107.32284.tho...@koch.ro
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#705128: ITP: libcofoja-java -- Java framework with annotation processing to provide runtime checkings

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: libcofoja-java
  Version : 1.0~r139
  Upstream Author : Google Inc
* URL : https://code.google.com/p/cofoja/
* License : LGPL
  Programming Lang: Java
  Description : Java framework with annotation processing to provide 
runtime checkings

Contracts for Java is a contract programming framework for Java, which
uses annotation processing and bytecode instrumentation to provide
run-time checking.

Developments are stalled for a while (2011) but cofoja is used by several other 
tools needing it to be packaged.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130410132517.15351.46599.report...@debiansid.irisa.fr

Re: [Debian-med-packaging] Question about proper archive area for packages that require big data for operation

[Olivier Sallou]

On 04/23/2013 11:48 AM, Laszlo Kajan wrote:
> Dear Russ, Debian Med Team, Charles!
>
> (Please keep Tobias Hamp in replies.)
>
> @Russ: Please allow me to include you in a discussion about a few 
> bioinformatics packages that depend on big, but free data [2]. I have cited
> your opinion [3] in this discussion before. You are on the technical 
> committee and on the policy team, so you, together with Charles, can help
> substantially here.
>
> [2] 
> http://lists.alioth.debian.org/pipermail/debian-med-packaging/2013-April/thread.html
> [3] https://lists.debian.org/debian-vote/2013/03/msg00279.html
>
> This email is to continue the discussion about free packages that depend on 
> big (e.g. >400MB) free data outside 'main'. These packages
> apparently violate policy 2.2.1 [0] for inclusion in 'main' because they 
> require software outside the 'main' area to function. They do not
> violate point #1 of the social contract [1], which requires non-dependency on 
> non-free components. For these big data packages, policy seems to
> be overly restrictive compared to the social contract, leading to seemingly 
> unfounded rejection from 'main'.
Indeed, many bioinformatics programs relies on external data. But I am
afraid that if we start to add some data packages, we will open an
endless open door BioInformatics datasets are large, and becoming
huge and numerous.
This size will be an issue for Debian mirrors (mainly if some indexed
data are system dependent) but will also be a pain for the user if, when
installing a program (to have a look), it downloads GBs of dependent
packaged data. It may be really slow and fill the user disk (and I do
not talk of package updates).

Should not those data dependency clearly stated somewhere with the
software package, with a script to get them ?

Olivier
>
> [0] http://www.debian.org/doc/debian-policy/ch-archive.html
> [1] http://www.debian.org/social_contract
>
> * In case the social contract indeed allows such packages to be in 'main' 
> (and policy is overly restrictive), how could it be ensured that the
> packages are accepted?
>
> * What is the procedure within Debian to elicit a decision about the handling 
> of such packages in terms of archive area? Discussion on d-devel,
> followed by policy change? Asking the policy team to clarify policy for such 
> packages? Technical committee?
>
>  + Charles suggested such packages could go into 'main' [4], with a clear 
> indication of the large data dependency of the package in the long
> description.
>When possible, providing the scripts for generating the large data as well.
>
>  [4] 
> http://lists.alioth.debian.org/pipermail/debian-med-packaging/2013-April/019292.html
>
> My goal as a Debian Developer and a packager is to get packages into Debian 
> (so 'main') that are allowed in there, in reasonably short time. I
> would like to resolve this issue properly, because I believe it may pop up 
> more often in bioinformatics software. For example, imagine a protein
> folding tool that would require a very large database to search for 
> homologues for contact prediction, and using the contacts it would predict
> protein three-dimensional structure. This has been done before [5], and such 
> a tool would be (is) immensely useful for bioinformatics. This tool
> would depend on gigabytes of data we would not package. Yet, by all means, I 
> would want the tool to be part of the distribution.
>
> [5] http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0028766
>
> Thank you for your opinion and advice.
>
> Best regards,
> Laszlo
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51777990.60...@irisa.fr

Re: [Debian-med-packaging] Question about proper archive area for packages that require big data for operation

[Olivier Sallou]

On 04/24/2013 04:02 PM, Laszlo Kajan wrote:
> Hello Didier!
>
> On 24/04/13 09:32, Didier 'OdyX' Raboud wrote:
>> Le mardi, 23 avril 2013 12.23:23, Andreas Tille a écrit :
>>> I would even go that far that it might make sense to package these data
>>> and upload it to demonstrate that we should *really* create a solution
>>> for such cases if they will increase in the number and size of data
>>> packages.
>> Isn't that what data.debian.org is supposed to be(come) ?
>>
>>  * http://ftp-master.debian.org/wiki/projects/data/
>>  * http://lists.debian.org/debian-devel/2010/09/msg00692.html
> Thanks for pointing this out, I didn't know about this. This would work very 
> well for the 'metastudent' (and other of the same kind) data. A
> policy change (point 'We need to change policy.' of [1]) could be initiated, 
> as Russ Allbery noted before [2]. But - data.debian.org does not
> (yet) exist, does it?
sounds idea is quite old (2009) but did not progress. Could be the
opportunity to relaunch it.
> [1] http://ftp-master.debian.org/wiki/projects/data/
> [2] 
> http://lists.alioth.debian.org/pipermail/debian-med-packaging/2013-April/019320.html
>
> Laszlo
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5177ec98.5040...@irisa.fr

issue with svn repo?

[olivier sallou]

Hi,
are you experimenting issues with svn access to debian repo (svn and
anonsvn) ?

I can't connect anymore and when trying to browse the code, I have access
errors

http://anonscm.debian.org/viewvc/debian-med/trunk

Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#732990: ITP: readseq2 -- readseq2 is a rewrite of readseq converter

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: readseq2
  Version : 2.1.30
  Upstream Author : D. Gilbert 
* URL : http://iubio.bio.indiana.edu/soft/molbio/readseq/java/
* License : Public Domain
  Programming Lang: Java
  Description : readseq2 is a rewrite of readseq converter

 Reads and writes nucleic/protein sequences in various
 formats. Data files may have multiple sequences.
 Readseq is particularly useful as it automatically detects many
 sequence formats, and converts between them.
 .
 This is the rewrite of the original C version which is available
 as well in Debian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131223162225.7576.53133.report...@debiansid.irisa.fr

Bug#735158: ITP: minia -- short-read assembler

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: minia
  Version : 1.6067
  Upstream Author : Rayan 
* URL : http://minia.genouest.org
* License : CeCILL
  Programming Lang: C
  Description : short-read assembler

Minia is a short-read assembler based on a de Bruijn graph, capable of 
assembling a human genome on a desktop computer in a day. The output of Minia 
is a set of contigs. Minia produces results of similar contiguity and accuracy 
to other de Bruijn assemblers (e.g. Velvet).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140113110343.9155.6839.report...@debiansid.irisa.fr

Re: Bug#732878: Add MariaDB as an alternative dependency

[olivier sallou]

2014/1/17 Otto Kekäläinen 

> 2013/12/30 Otto Kekäläinen :
> > We discussed this on the pkg-maint-mysql list and the recommended policy
> is now:
> >
> > All packages that at the moment depend directly on mysql-client should
> > instead have something like:
> >
> > Depends: the-one-they-tested-with | virtual-mysql-client
> > (or Suggests or Recommends)
>

Do you know if libmysql-java is compatible with MariaDB ? I see no
libmariadb-java for the moment in archive.
I suppose there will be one as MariaDb propose Java driver on its web site.
But will it follow the same rule with a kinda libvirtual-mysql-java ?

Olivier

>
> > At the moment in unstable the packages mysql-server-5.5 and
> > mariadb-server-5.5 have
> > Provides: mysql-virtual-server
> >
> > and mysql-client-5-5 and mariadb-client-5.5 have
> > Provides: mysql-virtual-client
> >
> > Later when other versions are uploaded to Debian (e.g. MySQL 5.6,
> > MariaDB 10, Percona etc) they will include the same provides as long
> > as they are compatible enough with MySQL 5.5 to be
> > drop-in-replacements.
> >
> > Does this sound OK?
>
>
> Just for the record, I've written down now this policy at
> https://wiki.debian.org/Teams/MySQL/virtual-mysql-server and it is now
> in effect as there was no other contersuggestions, and both the MySQL
> packages and MariaDB packages in Debian already abide to this policy.
>
>
> --
> Otto Kekäläinen
> +358 44 566 2204
> http://seravo.fi/
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/cahj_tlcsbrwrta7o0utnq8ouysbg6xyknox8z1q+sxaa3-...@mail.gmail.com
>
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#737098: ITP: discosnp -- discovering Single Nucleotide Polymorphism (SNP) from raw set(s) of reads obtained with Next Generation Sequencers

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: discosnp
  Version : 1.0.1
  Upstream Author : INRIA
* URL : http://colibread.inria.fr/discosnp/
* License : CeCILL
  Programming Lang: C
  Description : discovering Single Nucleotide Polymorphism (SNP) from raw 
set(s) of reads obtained with Next Generation Sequencers

Software discoSnp is designed for discovering Single Nucleotide Polymorphism 
(SNP) from raw set(s) of reads obtained with Next Generation Sequencers (NGS).
Note that number of input read sets is not constrained, it can be one, two, or 
more. Note also that no other data as reference genome or annotations are 
needed.
The software is composed by two modules. First module, kissnp2, detects SNPs 
from read sets. A second module, kissreads, enhance the kissnp2 results by 
computing per read set  and for each found SNP i/ its mean read coverage and 
ii/ the (phred) quality of reads generating the polymorphism.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140130083914.5249.82438.report...@debiansid.irisa.fr

Bug#737099: ITP: mapsembler2 -- bioinformatics targeted assembly software

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: mapsembler2
  Version : 2.0.5
  Upstream Author : INRIA
* URL : https://colibread.inria.fr/mapsembler2/
* License : CeCILL
  Programming Lang: C
  Description : bioinformatics  targeted assembly software

Mapsembler2 is a targeted assembly software. It takes as input a set of NGS raw 
reads (fasta or fastq, gzipped or not) and a set of input sequences (starters). 
It first determines if each starter is read-coherent, e.g. whether reads 
confirm the presence of each starter in the original sequence. Then for each 
read-coherent starter, Mapsembler2 outputs its sequence neighborhood as a 
linear sequence or as a graph, depending on the user choice.
Mapsembler2 may be used for (not limited to):
· Validate an assembled sequence (input as starter), e.g. from a de Bruijn 
graph assembly where read-coherence was not enforced.
· Checks if a gene (input as starter) has an homolog in a set of reads
· Checks if a known enzyme is present in a metagenomic NGS read set.
· Enrich unmappable reads by extending them, possibly making them mappable
· Checks what happens at the extremities of a contig
· Remove contaminants or symbiont reads from a read set


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140130084205.5344.82013.report...@debiansid.irisa.fr

Fwd: Microsoft Azure provider available in bootstrap-vz

[olivier sallou]

-- Message transféré --
De : "olivier sallou" 
Date : 8 avr. 2014 09:05
Objet : Microsoft Azure provider available in bootstrap-vz
À : "debian-cloud" 
Cc :

Hi,
I have just finished the provider for Microsoft Azure on bootstrap-vz, in
the development branch for the moment.
I have tested it with boot/reboot/disk atttachement and everytinh looks
fine.

If someone wants to make some testing to validate it (please read the
REAME in the bootstrapvz/provider/azure for requirements)

Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

problem with web site http://packages.debian.org/

[olivier sallou]

Hi,
there is an issue with one of my packages with the displayed description.

http://packages.debian.org/sid/biomaj

It displays:


Binary utilities supporting TI's MSP430 targetsPackage: biomaj (1.1.0-3)

The programs in this package are used to manipulate binary and object files
that may have been created for TI's MSP430 architecture. This package is
primarily intended for MSP430 developers and cross-compilers.

***

Though, the description is not at all the correct one . The problem occured
after my package update from 1.1.0-2 to 1.1.0-3. Previous one was correct.

Sometimes, after forcing a refresh in my navigator, the web site shows me
the "old" version 1.1.0-2.(with the correct description), even though
the version 1.1.0-3 is present (
http://ftp.de.debian.org/debian/pool/main/b/biomaj/). Maybe a mirroring
issue?

I checked my description in control file and it is correct (I downloaded the
file from debian ftp site to be sure)


Can someone drive me to the correct person to contact?


Thanks


Olivier

Re: Providing official virtualisation images of Debian

[olivier sallou]

Debian live provide has the possibility to generate raw images with custom
configuration.
Only problem here is it is to generate livecd instead of a ready to run
image.
Adding this possiblity would provide VM for Debian but also Debian users to
create their own Debian customized VM.
Raw format can be easily converted to other formats.
I talked some time ago with one of the developpers on Debian Live and was
expecting to do so this summer (if he has  some time...). Unfortunatly, I am
not an expert enough on kernel/system to help
For Amazon AMI, constraint is on Kernel/Ramfs. On amazon, those are not in
the image(disk) but separated, and cannot be provided. Those must be
pre-uploaded on amazon, and only some providers can do so (Ubuntu is one of
them).

Olivier

2011/7/26 Daniel Baumann 

> On 07/26/2011 12:27 AM, Moritz Mühlenhoff wrote:
> > I believe it's high time we start to providing Debian in form of official
> > virtualisation images.
>
> we have worked on that with debian-live (both producing live and
> 'non-live' images; the only difference is that live-* is not installed
> in the rootfs), and provide soon vbox (and if interest, any other image
> type) for this.
>
> you might want to hold on for after debconf.
>
> --
> Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
> Email:  daniel.baum...@progress-technologies.net
> Internet:   http://people.progress-technologies.net/~daniel.baumann/
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/4e2eace5.5070...@progress-technologies.net
>
>

Re: Providing official virtualisation images of Debian

[olivier sallou]

Let's not just forget that Amazon EC2 AMI is a nice thing to provide, but
interface to get ssh-keys etc... (just look at ip used to get meta data) is
propriatory and will not work with other cloud softwares (public or private,
such as open nebula/open stack).
Only EC2 interface is shared to manage the interface, but not the init
scripts required etc...

So Debian would need to create virtuals machines images specific to Amazon
but also some others...

Generic images (basic vm with ssh logging instead of using ssh keys) would
be required for use in private clouds or just companies/users using virtual
machines...


Olivier

2011/7/31 Charles Plessy 

> Le Sat, Jul 30, 2011 at 11:44:00PM -0400, Yar oslav Halchenko a écrit :
> > Thank you Steffen -- very informative (at least to me, who has not went
> > into the cloud yet) and in general I share your side.
> >
> > do you know if alestic guys are planing on preparing an AMI with
> > squeeze?
>
> No plans… http://groups.google.com/group/ec2debian/msg/8f12b422f881dbaa
>
> Currently there are some Squeeze AMIs made available, and they are probably
> good, but none of them is as strongly established as ‘the’ Debian AMIs as
> Alsetic's are for Ubuntu.
>
> I think that one way to get more blessing in Debian AMIs would be to build
> them
> entirely from material distributed in Debian.  Luckily, as you have seen in
> some other messages, it looks possible.
>
> Cheers,
>
> --
> Charles Plessy
> Debian Med packaging team,
> http://www.debian.org/devel/debian-med
> Tsurumi, Kanagawa, Japan
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/20110731044003.gb29...@merveille.plessy.net
>
>

Fwd: Re: BLAST+ speed & build issues

[Olivier Sallou]

)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f06d11d8000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f06d0fc)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f06d0db8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f06d0b9b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f06d0891000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f06d060f000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f06d03f8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f06d0074000)
/lib64/ld-linux-x86-64.so.2 (0x7f06d97e6000)


For a simple "-h" call, here is a benchmark:

# Static build"
osallou@debiansid:/tmp/ncbi-blast-2.2.25+-src/debian/ncbi-blast+/usr/bin$ time
bash -c 'for (( c=1; c<=50; c++ )) ; do ./blastx -h > /dev/null ; done'

real0m0.403s
user0m0.292s
sys0m0.124s

# Dynamic build
osallou@debiansid:/tmp/ncbi-blast-2.2.25+-src/debian/ncbi-blast+/usr/bin$ time
bash -c 'for (( c=1; c<=50; c++ )) ; do blastx -h > /dev/null ; done'

real0m8.002s
user0m4.200s
sys0m3.856s


---- Message original 
Sujet:  Re: BLAST+ speed & build issues
Date de renvoi :Thu, 4 Aug 2011 09:31:54 + (UTC)
De (renvoi) :   debian-...@lists.debian.org
Date :  Thu, 04 Aug 2011 11:31:34 +0200
De :Olivier Sallou 
Pour :  Tim Booth 
Copie à :   debian-...@lists.debian.org, "Aaron M. Ucko" 



Hi,
I quickly build the ncbi-blast+ locally with static build using the
debian build process, and indeed,
static build binaries are much faster (blastx -h) than dynamically
linked ones.

I will investigate if there is a way to speedup this. Or if anyone has
ideas

Olivier

Le 8/3/11 10:48 AM, Tim Booth a écrit :
> time bash -c 'for (( c=1; c<=50; c++ )) ; do 
> ~/tings/ncbi-blast-2.2.25+/bin/blastx -h > /dev/null ; done'

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e3a66f6.7040...@irisa.fr

Re: Fwd: Re: BLAST+ speed & build issues

[olivier sallou]

Linking against "needed" lib is quite difficult (would need to be done on
upstream), package is rather complex regarding compilation.
And each solution has its pros and cons

I think we will have to discuss on validity to provide static builds ( takes
a lot of space on package vs perf loss)

Thanks anyway

2011/8/4 Samuel Thibault 

> Julian Taylor, le Thu 04 Aug 2011 12:32:27 +0200, a écrit :
> > You might be able to reduce startup time by only linking against the
> > libraries you need or lazyly dynamically loading them.
>
> Or use prelink.
>
> Samuel
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> http://lists.debian.org/20110804112744.gf4...@type.bordeaux.inria.fr
>
>

Bug#637109: ITP: pycaptcha -- collection of Python modules implementing CAPTCHAs

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: pycaptcha
  Version : 2.4
  Upstream Author :  Micah Dowty 
* URL : http://pypi.python.org/pypi/PyCAPTCHA/0.4
* License : MIT
  Programming Lang: Python
  Description : collection of Python modules implementing CAPTCHAs

This is the PyCAPTCHA package, a collection of Python modules
implementing CAPTCHAs: automated tests that humans should pass,
but current computer programs can't. These tests are often
used for security.

See  http://www.captcha.net for more information and examples.

This project was started because the CIA project, written in
Python, needed a CAPTCHA to automate its user creation process
safely. All existing implementations the author could find were
written in Java or for the .NET framework, so a simple Python
alternative was needed.

Examples


Included are several example programs:

  - simple_example.py is a bare-bones example that just generates
and displays an image.

  - http_example.py is a longer example that uses BaseHTTPServer
to simulate a CAPTCHA's use in a web environment. Running this
example and connecting to it from your web browser is a quick
and easy way to see PyCAPTCHA in action

  - modpython_example.py is a version of http_example that runs
from an Apache server equipped with a properly configured
mod_python.


Dependencies


- Python 2.2.1 or later
- the Python Imaging Library, required for visual CAPTCHAs



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110808142956.15037.8515.report...@debiansid.genouest.org

Bug#637230: ITP: mobyle -- Mobyle is a wbe portal and framework to provide web interfaces to command-line tools. It is designed though not limited for bioinfomatics.

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: mobyle
  Version : 1.0.0
  Upstream Author : Herve Menager 
* URL : https://projets.pasteur.fr/wiki/mobyle/download
* License : GPL
  Programming Lang: Python
  Description : Mobyle is a web portal and framework to provide web 
interfaces to command-line tools. It is designed though not limited for 
bioinformatics

Mobyle is a framework and web portal specifically aimed at the integration of 
bioinformatics software and databanks.

It is developed jointly by the Projets et Développements en Bioinformatique 
team of the Institut Pasteur and the Ressource Parisienne en Bioinformatique 
Structurale.
It can be compared to the Galaxy tool.

Depends: python (>= 2.5), apache2, python-simpletal (>=4.1), python-simplejson 
(>= 1.7.1), python-imaging (>= 1.1.5),
 python-lxml (>= 2.2.4), squizz, python-pycaptcha, libjs-scriptaculous, 
libjs-jquery, libjs-prototype
Suggests: python-openid (>= 2.2.4), python-dnspython (>= 1.5.0)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110809171128.15542.80237.report...@debiansid.genouest.org

how to debug test build issues form Debian servers

[olivier sallou]

Hi,
I have a package that fails some tests on a few architectures.
Looking at logs from those servers, it seems that it is quite random (not
always same arch, or same tests), could be due to some timeouts in tests
etc...
I am not upstream author, impacted tests are not easy to debug. And log show
no detail except log failure count (and which test).

Should I create a new package version (upstreamversion-X) and upload it to
sid then wait for the build of each arch to check if my patch work ? and
create new version again if patch is not the expected one ?
This could lead to many patched package upload just for test

Indeed, test failure seem related to the build/test servers (lower RAM,
higher cpu load generating timeout?).


Thanks for any suggestion.

Olivier

Bug#639868: ITP: chado -- Chado is a relational database schema that underlies many GMOD installations.

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 


* Package name: chado
  Version : 1.11
  Upstream Author : GMOD
* URL : http://gmod.org/wiki/Chado_-_Getting_Started
* License : Artistic License 2.0
  Programming Lang: Perl,SQL
  Description : Chado is a relational database schema that underlies many 
GMOD installations.

It is capable of representing many of the general classes of data frequently
 encountered in modern biology such as sequence, sequence comparisons,
 phenotypes, genotypes, ontologies, publications, and phylogeny.

 It has been designed to handle complex representations of biological
 knowledge and should be considered one of the most sophisticated
 relational schemas currently available in molecular biology.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110831070947.9443.37605.report...@debiansid.genouest.org

load of apache module for a package

[olivier sallou]

Hi,
I need some apache modules for a package.

Should I use a2enmod in postinst script, or, is there any debhelper/deb file
way to do it?

Thanks

Olivier

Re: Javascript trigger design

[olivier sallou]

Le Fri Nov 28 2014 at 01:55:26, Tomas Pospisek  a
écrit :

> Am 28.11.2014 um 00:04 schrieb Thomas Goirand:
> > Hi,
> >
> > Web application have evolved into monsters that needs lots of
> > javascript. It's very common that these javascript applications are
> > collecting all the .js library they use, concatenate them into a single
> > file, and compress the result using all sorts of tools (node uglify is
> > one of the implementation, but that's not the only one).
> >
> > As much as possible, as good Debian citizens, we do package each and
> > every javascript library into a separate package. But then, if there's
> > an update of that JS library, the Web application package has to somehow
> > know about it, and redo the concatenate & compress job. Otherwise, the
> > web app would continue to use the old version.
> >
> > I have this issue with the OpenStack dashboard (ie: Horizon), but also
> > with a second web app which I'm currently packaging (OpenStack Fuel,
> > which is a deployment software for OpenStack). Though this could of
> > course be generalize to any JS app.
> >
> > It's been a long time I've been thinking about it, and I believe that
> > the only way to do this, would be to use triggers. Though I have never
> > used triggers, and I thought it was a good idea to ask my DD friends and
> > this list about it. Should there be one trigger per web app? How would
> > this work?
> >
> > Thoughts anyone? Jonas maybe, who did lots of JS packaging?
>
> At least the Ruby On Rails framework notices an updated JS and will
> re-compress the whole JS blob from its parts. I don't know about other
> server side frameworks, but they _should_ be able to do the same. - ?

Unfortunalty no. Many "frameworks" help you build such things but with no
update detection. Many frameworks are not running server like RoR but only
build tools (Grunt, Yeoman, ...)
These tools concat/minify/uglify etc... at build time and then you just put
your app under Apache/Nginx and a different language server (to manage the
GUI).
So there is no awy for all these tools to detect a change and automatically
do the modification.

1) A trigger mechanism could indeed inform an additional script (that
Debian developper/maintainer should develop per app) and this script could
do the job, but on "production" system, I do not think that you would want
to do automatically this because this may imply other things, and/or many
compilation on your server at the same time (think of a jquery update
triggering update of all dependent platforms...).

2) One thing could be that a dependency update triggers a rebuilt of the
package with a kinda automatic minor version upgrade and you would
benefit from it at next system/app update.

>From a deveopper point of view (which I am), I would like idea 1, but from
an admin point of view I think it would be idea 2.


Olivier



> Or
> there shoould be some switch or some additional plugin or such that
> enables the same functionality.
>
> Or do I missunderstand you?
> *t
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/5477c7b4.90...@sourcepole.ch
>
>

Any way to apply patch on some archs only?

[olivier sallou]

Hi
I d like to know if it is posdible to apply a patch on some archs only.
I have some FTBS on some archs for a package. I have a patch but I d like
to apply it only on failings archs and keep original upstream code for
others.

Patches can indeed fix an issue but be less performant/optimal...

I could not find a way to do so, but i am sure some others already faced
the case before me and can drive me to the doc i did not find :-)

Thanks

Olivier

Re: Any way to apply patch on some archs only?

[olivier sallou]

Le Thu Jan 29 2015 at 7:29:20 AM, Jackson Doak  a
écrit :

> I don't know the exact way, but you can do it with some debian/rules magic.
> What's the issue with patching the non-affected arches?
>
I could in this specific case, but I do not know the real impact of the
patch. I think that if upstream used this solution, it may be because it is
best, even if both work.

In a more general way, there may be cases where a patch is needed for one
arch and not for an other, and may add complex setups to make it work in
any case. Applying patch only on failing arch would certainly ease some
cases.

>
> On Thu, Jan 29, 2015 at 5:26 PM, olivier sallou 
> wrote:
>
>> Hi
>> I d like to know if it is posdible to apply a patch on some archs only.
>> I have some FTBS on some archs for a package. I have a patch but I d like
>> to apply it only on failings archs and keep original upstream code for
>> others.
>>
>> Patches can indeed fix an issue but be less performant/optimal...
>>
>> I could not find a way to do so, but i am sure some others already faced
>> the case before me and can drive me to the doc i did not find :-)
>>
>> Thanks
>>
>> Olivier
>>
>
>

Re: Any way to apply patch on some archs only?

[olivier sallou]

Le Thu Jan 29 2015 at 9:11:08 AM, Raphael Hertzog  a
écrit :

> Hi,
>
> On Thu, 29 Jan 2015, olivier sallou wrote:
> > I d like to know if it is posdible to apply a patch on some archs only.
> > I have some FTBS on some archs for a package. I have a patch but I d like
> > to apply it only on failings archs and keep original upstream code for
> > others.
> >
> > Patches can indeed fix an issue but be less performant/optimal...
> >
> > I could not find a way to do so, but i am sure some others already faced
> > the case before me and can drive me to the doc i did not find :-)
>
> Best practices are to have a patch that can be used on all architectures
> so that it can be submitted upstream. When you need architecture specific
> behaviour, then you need code that will test some architecture-specific
> variable/macros.
>
> In C you would usually use the preprocessor's #ifdef directives. If you
> need more guidance, then you need to provide more details.
>

In C/C++ I know the way to do this, but you cannot always do that in all
languages.
In my current case, I can apply on all archs if needed, but I wondered if
there was an easy way, seems not... :-(
Thanks

>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get/
>

Re: Any way to apply patch on some archs only?

[olivier sallou]

Le Thu Jan 29 2015 at 9:58:18 AM, Paul Wise  a écrit :

> On Thu, Jan 29, 2015 at 4:16 PM, olivier sallou wrote:
>
> > In my current case, I can apply on all archs if needed, but I wondered if
> > there was an easy way, seems not... :-(
>
> Please post some details of the bug, the patch you want to apply and
> which package you are talking about so that we can give you a better
> answer to your question.
>
As I said, I can manage it for my current bug, but my question is a more
general question.

>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/CAKTje6EXBWKcrrFp=_nf_
> n52xyt8l18bgtzyvh5mkpgpnc9...@mail.gmail.com
>
>

Fwd: Any way to apply patch on some archs only?

[olivier sallou]

Forgot to CC the list

-- Forwarded message -
From: olivier sallou 
Date: jeu. 29 janv. 2015 15:20
Subject: Re: Any way to apply patch on some archs only?
To: Ian Jackson 


Sorry for quoting, sent from my phone...
Yes this is this bug. Upstream will add conditions in code (ifdef...). This
is fine because it is C, but for some other languages it may be more
complex to test this.

Le jeu. 29 janv. 2015 14:58, Ian Jackson 
a écrit :

olivier sallou writes ("Re: Any way to apply patch on some archs only?"):
> > Le Thu Jan 29 2015 at 9:58:18 AM, Paul Wise  a écrit :
> > > Please post some details of the bug, the patch you want to apply and
> > > which package you are talking about so that we can give you a better
> > > answer to your question.
>
> I think it's this one
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765285
>
> > As I said, I can manage it for my current bug, but my question is a more
> > general question.
>
> Have I found the `current bug' you are thinking of ?
>
> Ian.
>

Re: what's the difference between [s/i/m/l/k/n] ?

[olivier sallou]

Sorry for quoting, sent from my phone.

This impacts d/control only to use a different template. Do not forget it
is a helper only.  s/m...  will only propose a different control
schema/fields autofilled according to your choice.

Olivier

Le dim. 1 mars 2015 07:12, lumin  a écrit :

Hi guys,

When learning on how to package software,
I am confused about what's the difference between the
essence of [s/i/m/l/k/n].
(single binary, indep binary, multiple binary, ...)

the man page of dh_make(8) briefly explained what the diff
between them __without_revealing_the_essence__.

the maint-guide (debian new maintainer's guide) says so:
There are several choices here: s for Single binary package, i
for
***
outside the scope of this document.
and maint-guide didn't hint where the answer lies.

After some experiments with dh_make, I found that,
[s/i/m/l/k/n] affects at least file debian/control.

As lacking of documentation, I wonder that,
if [s/i/m/l/k/n] only affects debian/control and affect nothing except
for control?



P.S. If there is need to explain the difference on essence between
s/i/m/l/k/n clearly, I think it's good to file a bug againt maint-guide?

Thanks. :-)
--
Regards,
  C.D.Luminate

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
Archive: https://lists.debian.org/1425189276.2931.16.ca...@gmail.com

Bug#783833: ITP: python-obitools -- set of programs specifically designed for analyzing NGS data in a DNA metabarcoding contex

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: python-obitools
  Version : 1.1.16
  Upstream Author : Eric Coissac
* URL : http://metabarcoding.org//obitools/
* License : CeCILL-V2
  Programming Lang: Python
  Description : set of programs specifically designed for analyzing NGS 
data in a DNA metabarcoding contex

The OBITools package is a set of programs specifically designed for analyzing 
NGS data in a DNA metabarcoding context, taking into account taxonomic 
information.
OBITools enrich the Unix command line interface with a set of new commands 
dedicated to NGS data processing. Most of them have a name starting with the 
obi prefix. They automatically recognize the input file format amongst most of 
the standard sequence file formats (i.e. fasta, fastq, EMBL, and GenBank 
formats). Nevertheless, options are available to enforce some format 
specificity such as the encoding system used in fastq files for quality codes. 
Most of the basic Unix commands have their OBITools equivalent (e.g. obihead vs 
head, obitail vs tail, obigrep vs grep), which is convenient for scientists 
familiar with Unix. The main difference between any standard Unix command and 
its OBITools counterpart is that the treatment unit is no longer the text line 
but the sequence record. As a sequence record is more complex than a single 
text line, the OBITools programs have many supplementary options compared to 
their Unix equivalents.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150430151303.27807.4848.reportbug@debian

Re: Bug#783833: ITP: python-obitools -- set of programs specifically designed for analyzing NGS data in a DNA metabarcoding contex

[olivier sallou]

Le jeu. 30 avr. 2015 à 17:42, Scott Kitterman  a
écrit :

> On Thursday, April 30, 2015 05:13:03 PM Olivier Sallou wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Olivier Sallou 
> >
> > * Package name: python-obitools
> >   Version : 1.1.16
> >   Upstream Author : Eric Coissac
> > * URL : http://metabarcoding.org//obitools/
> > * License : CeCILL-V2
> >   Programming Lang: Python
> >   Description : set of programs specifically designed for analyzing
> NGS
> > data in a DNA metabarcoding contex
> >
> > The OBITools package is a set of programs specifically designed for
> > analyzing NGS data in a DNA metabarcoding context, taking into account
> > taxonomic information. OBITools enrich the Unix command line interface
> with
> > a set of new commands dedicated to NGS data processing. Most of them
> have a
> > name starting with the obi prefix. They automatically recognize the input
> > file format amongst most of the standard sequence file formats (i.e.
> fasta,
> > fastq, EMBL, and GenBank formats). Nevertheless, options are available to
> > enforce some format specificity such as the encoding system used in fastq
> > files for quality codes. Most of the basic Unix commands have their
> > OBITools equivalent (e.g. obihead vs head, obitail vs tail, obigrep vs
> > grep), which is convenient for scientists familiar with Unix. The main
> > difference between any standard Unix command and its OBITools counterpart
> > is that the treatment unit is no longer the text line but the sequence
> > record. As a sequence record is more complex than a single text line, the
> > OBITools programs have many supplementary options compared to their Unix
> > equivalents.
>
> According to the trove information on pypi [1] this is python only, not
> python3.  We were hoping to not increase the amount of python packages
> needing
> porting to python3.  Have you discussed python3 plans with upstream?
>

Nope, not yet. However, as I discussed with one guy of the team some time
ago, I do not think there is any plan to go to python3.
This is an academic tool, and very often, they only focus on getting
something working and base maintenance.

I understand the need to plan python3 switch, however we cannot block tools
used by the community.

I will ask upstream anyway.



> Scott K
>
> [1] https://pypi.python.org/pypi/OBITools/1.1.16
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/21039320.xThH8BtM62@kitterma-e6430
>
>

Re: Bug#783833: ITP: python-obitools -- set of programs specifically designed for analyzing NGS data in a DNA metabarcoding contex

[olivier sallou]

Le jeu. 30 avr. 2015 à 23:57, Ben Hutchings  a écrit :

> On Thu, 2015-04-30 at 16:23 +0000, olivier sallou wrote:
> [...]
>
> > Nope, not yet. However, as I discussed with one guy of the team some
> > time ago, I do not think there is any plan to go to python3.
> > This is an academic tool, and very often, they only focus on getting
> > something working and base maintenance.
> >
> >
> > I understand the need to plan python3 switch, however we cannot block
> > tools used by the community.
> [...]
>
> Yes we can.  There are many popular programs not packaged in Debian
> because they do not meet our standards.
>

So what is the plan for Debian? I have seen some discussions on
Debian-devel about the subject, but I saw no clear stop for non-python3
packages (at least not yet).

Should we definitly stop importing Python2 only packages in Debian,
considering that most of python packages are still v2 only? (mainly due to
dependencies themselves in v2 only) ?

Ben, I kept you CC'ed in the mail, but please tell me if you prefer that
discussion continues on debian-devel/bug only.

Olivier

>
> Ben.
>
>
> --
> Ben Hutchings
> A free society is one where it is safe to be unpopular. - Adlai Stevenson
>

Bug#795865: ITP: bio-rainbow -- RAD-seq related clustering and de novo assembly

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: bio-rainbow
  Version : 2.4.0
  Upstream Author : Jue Ruan 
* URL : http://sourceforge.net/projects/bio-rainbow/
* License : GPL
  Programming Lang: C, Perl
  Description : RAD-seq related clustering and de novo assembly

Rainbow package consists of several programs used for RAD-seq related 
clustering and de novo assembly. in bioinformatics

Bug#796289: ITP: python-eta -- python module to generate progress bar for CLI

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: python-eta
  Version : 0.9.7
  Upstream Author : Marcus Breese
* URL : https://github.com/mbreese/eta
* License : BSD
  Programming Lang: Python
  Description : python module to generate progress bar for CLI

This is a python module that will create progress bars for command-line 
programs.

This pakcage is a dependency for an other package to come ngsutils.

Bug#796363: ITP: libsis-base-java -- supplies some utility classes needed for libraries like sis-jhdf5

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: libsis-base-java
  Version : 14.12.0
  Upstream Author : ETH Zuerich, CISD
* URL : https://wiki-bsse.ethz.ch/display/JHDF5/Download+Page
* License : Apache
  Programming Lang: C, Java
  Description : supplies some utility classes needed for libraries like 
sis-jhdf5

Base libraries used by software from the SIS division at ETH Zurich
 This library supplies some utility classes needed for libraries like sis-jhdf5.

Bug#796390: ITP: libsis-jhdf5-java -- HDF library for Java

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: libsis-jhdf5-java
  Version : 14.12.1
  Upstream Author : ETH Zuerich CISD
* URL : http://svncisd.ethz.ch/repos/cisd/jhdf5/tags/release/
* License : Apache
  Programming Lang: C, Java
  Description : HDF library for Java

JHDF5 is a Java binding to the HDF Group library for HDF5 focusing on
ease-of-use, which was developed by CISD and is now maintained by ETH SIS.
The library uses HDF5 1.8 from the HDF Group and files created with
JHDF5 are fully compatible with HDF5 1.6/1.8 (as you choose).

Bug#796487: ITP: repeatmasker-recon -- indentification of repeat families from biological sequences

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: repeatmasker-recon
  Version : 1.08
  Upstream Author : Institute for Systems Biology
* URL : http://www.repeatmasker.org/
* License : GPL
  Programming Lang: C, Perl
  Description : indentification of repeat families from biological sequences

The RECON package implements a de novo algorithm for the
indentification of repeat families from biological sequences.  For
details about the algorithm, see

Bao Z. and Eddy S.R. (2002) Automated de novo Identification of Repeat
Sequence Families in Sequenced Genomes. Submitted.

and

http://www.genetics.wustl.edu/eddy/recon

This distribution includes two Perl scripts and several C programs.
Most users only need to run the scripts and the C programs should be
transparent.

Re: Please help me to create Debian package

[olivier sallou]

Le jeu. 4 juil. 2019 à 18:31, Mindaugas Celiesius  a
écrit :

>
>
> > Hi, I am working on a project named Osdag. It is open-source software
> for the design of steel structures. I'm trying to create a Debian package
> for it and planning to add to Debian package repository. It would be a
> great help if someone could create a package for us or help us to create
> that. The stable code is available at
> https://static.fossee.in/osdag/installation-files/Osdag_ubuntu_installer_v2018.06.a.3839.tar.gz
> Our Github repo is https://github.com/osdag-admin Debian package will
> help us to reach out the number of users and help in further improvements
> from their feedback and suggestions. Please help me with this.
>

First step is to check that your dependencies are packaged in debian and
your software works with versions packaged in debian

Olivier

> > Thank you.
> Meow!
>
>
> Hello. Please check this https://wiki.debian.org/Packaging  and this
> https://www.debian.org/doc/devel-manuals#packaging-tutorial
> It is not difficult at all. I think you can do it yourself.
> --
>
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
> ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
> ⠈⠳⣄ A master species delegates.
>
>
>

Re: Please help me to create Debian package

[olivier sallou]

Le ven. 5 juil. 2019 à 22:24, himanshu Singh  a
écrit :

> Thanks,
> There is a small problem I'm facing is how to handle the installer bash
> script?
> how can I run it during installation? Its function is to install python
> dependencies,
>

You can't. In packages you specify other debian packages to install, they
must exist in debian.
For other files, during package creation you create/copy files in a a dir
representing the final install (/usr... /var...) and at package install
they are placed in those locations.

There are rules where to place files etc.. in debian package policy.

As it seems it is python based, you should first package your soft as a
python package + desktop files etc...
There are some helpers to package for debian  python packages


creating configuration files and desktop shortcut. Please have a look at it
>
> https://github.com/osdag-admin/UbuntuInstaller/blob/master/2-install-osdag.sh
>
>
>
>
> On Thu, Jul 4, 2019 at 9:53 PM Mindaugas Celiesius 
> wrote:
>
>>
>> Hello. Please check this https://wiki.debian.org/Packaging  and this
>> https://www.debian.org/doc/devel-manuals#packaging-tutorial
>> It is not difficult at all. I think you can do it yourself.
>> --
>>
>>
>
>

buster backports question/status

[olivier sallou]

Hi,
it may be a silly question, but doing some tests on a Debian buster, I got
errors trying to install a package from buster-backports.

I added to sources.list.d info to set buster-backports but i get this error:

E: The value 'buster-backports' is invalid for APT::Default-Release as such
a release is not available in the sources

Looking at https://backports.debian.org, I only see stretch info/links.

As buster is really new, I expect there is no package yet in
buster-backports, but I should not get errors trying to access it. And I am
surprise to not find any reference to it.

So, am I doing something wrong?

Thanks

Olivier

Re: buster backports question/status

[olivier sallou]

Le mer. 10 juil. 2019 à 11:08, Andrey Rahmatullin  a
écrit :

> On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote:
> > So, am I doing something wrong?
> You tried to install a package (what package? they don't exist) from a
> repo that doesn't exist.
>

I tried a package that is not in backports, it was just for test (for an
automation tool I use)
It should fail with a *package not found* , but should not fail about
buster-backports being non available.

Is the problem linked to buster-backports not existing yet ? Is backports
repo not created automatically on new releases?


> --
> WBR, wRAR
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: buster backports question/status

[olivier sallou]

Le mer. 10 juil. 2019 à 11:35, Andrey Rahmatullin  a
écrit :

> On Wed, Jul 10, 2019 at 11:29:01AM +0200, olivier sallou wrote:
> > I tried a package that is not in backports, it was just for test (for an
> > automation tool I use)
> > It should fail with a *package not found* , but should not fail about
> > buster-backports being non available.
> I don't think the failing command was apt install, but rather apt update?
>

Nope, only at install time, update succeeded.
I though that backport was immediately available with new releases, even if
empty. I understand that is not the case.
I will update my scripts to manage the backports *not available* case.

Anyway, thanks for your anssers.

>
> --
> WBR, wRAR
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#933390: ITP: python-ftputil -- high level library for python ftp

[olivier sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 
X-Debbugs-Cc: debian-devel@lists.debian.org,
python-modules-t...@lists.alioth.debian.org

* Package name: python-ftputil
  Version : 3.4
  Upstream Author : Stefan Schwarzer 
* URL : https://ftputil.sschwarzer.net/trac
* License : BSD
  Programming Lang: Python
  Description : high level library for python ftp

ftputil is a high-level FTP client library for the Python programming
language. ftputil implements a virtual file system for accessing FTP
servers, that is, it can generate file-like objects for remote files.
The library supports many functions similar to those in the os,
os.path and shutil modules. ftputil has convenience functions for
conditional uploads and downloads, and handles FTP clients and servers
in different timezones.

Needed by next release of biomaj package.
-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: Should singularity-container make it to next release?

[olivier sallou]

Le mer. 12 oct. 2022 à 18:08, Nilesh Patra  a écrit :

> Hi,
>
> src:singularity-container was lying around in a bad shape for several years
> and had missed 2 debian releases until me and Andreas picked it up again.
> It is currently in a reasonably good condition. I was excited to have it in
> stable release again, but I have a couple of doubts over it.
>
> 1. A little background:
> singularity-container sync the code from the upstream codebase for
> sylabs[1]
> and there also exists a community-maintained fork called apptainer.
> Sylabs singularity CE seems to sync up a lot of code with apptainer in
> many releases. The apptainer community announcement page about the split
> also
> hints towards saying similar stuff, but this is all the more confusing as
> it is
> hard to draw a line b/w them.
> A while back, I found a reddit comment[4] from the current maintainer of
> sylabs
> singularity which has a statement:
>
> | At this point there it appears that Apptainer 1.0 will be very close
> | to SingularityCE 3.9 which we released recently, given
> | the picks from SingularityCE into the code base.
>
> So I am absolutely confused if it makes sense to package apptainer at all
> or
> should I just let it be?
>

for the moment, I would be happy to have singularity itself. Adding its
fork is nice, but mean extra work so I think we should focus on "main" tool
for the moment and see after

>
> 2. The _more_ important question:
> There are CVEs being discovered in singularity-container -- no biggie.
> However, some
> of the CVE fixes are simply _hidden_ from the user view.
> As a concrete example, there was
> a "CVE-2021-33622" opened[5] against singularity-CE, and the only
> information
> upstream provides is that it has been fixed in the 3.7.x of the community
> edition
> but there is no information about _what_ the fix was.
> I tried asking upstream about this but did not get a pin-pointed reply[6]
> and it
> appears that upstream is somewhat discrete about these.
>
> A similar bug has been fixed in the latest release, CVE-2022-39237 here[7]
> but it
> does not say _what_ patch fixes it exactly.
> And the problem is that apptainer has addressed the exact same bug in
> its latest release and they too are un-clear about it[8].
>
> So my fear is that: Once singularity-container hits stable release, and
> there is
> a CVE being found. It'd be a hellhole for me/others to find what exactly
> fixed the CVE (unless it is being clearly stated), and apply that. The only
> option left would be to upgrade the package to fix the CVE and I don't
> know if
> release team would allow that.
>
> And I don't see this problem getting fixed with apptainer as well, since
> there
> are bugs that both the codebases would keep on inheriting from one another.
> And thus I am not sure if this situation is OK for stable release or not.
>

won't be OK for stable release which will expect only security fixes, no
full upgrades
many software do not provide such detailed information, and I agree that
required taskforce to follow CVE details in source code can be quite
complex to obtain (or even not feasible).
You also need knowledge of the tool/language.

Last resort is to keep CVEs open this is the case for different tools
:-(



>
> OTOH, singularity is an important package and many users would be happy to
> have
> it in stable -- I have even got a couple of bug reports/texts saying
> people are happy to see a new update of singularity.
>


+1 for important package for several communities :-)

Olivier



>
> Any opinions?
>
> [1]: https://github.com/sylabs/singularity
> [2]: https://github.com/apptainer/apptainer
> [3]: https://apptainer.org/news/community-announcement-20211130/
> [4]:
> https://www.reddit.com/r/HPC/comments/r61bto/comment/hmspn72/?utm_source=share&utm_medium=web2x&context=3
> [5]:
> https://support.sylabs.io/support/solutions/articles/4287130-3-5-8-security-release-cve-2021-33622-
> [6]: https://github.com/sylabs/singularity/issues/586
> [7]: https://github.com/sylabs/sif/security/advisories/GHSA-m5m3-46gj-wch8
> [8]: https://github.com/apptainer/apptainer/releases/tag/v1.1.2
>
> --
> Best,
> Nilesh
>

Re: Free open-source ONLYOFFICE Desktop Editors: Compile from source code for Debian repository

[olivier sallou]

Le mar. 19 mai 2020 à 16:48, Kseniya Fedoruk 
a écrit :

> Hi team,
>
> I'm Kseniya from ONLYOFFICE. We are developing open-source office
> applications, including the absolutely free ONLYOFFICE Desktop Editors that
> provide alternatives to MS Office Word, Excel, and PowerPoint distributed
> under GNU AGPL v3.0.
>
> Currently, users can install the suite on various Linux distros from deb,
> rpm, Snap, Flatpak, and AppImage. We often receive requests for the
> native default support. Therefore, we’ve decided to contact you to ask
> about a possible integration of ONLYOFFICE Desktop Editors into Debian.
>
One point you need to know is, for a package to be in debian, package
should not depend on external resources, all resources need to be in Debian.
I got a very quick look at your build script, and it make use of *node
install* commands for example. But in Debian, it means that all needed npm
packages must be already packages (or to be packaged)

It also needs to compile/run with current versions of libraries available.
For example, default jdk in latest debian is jdk11 so user would run
onlyoffice with this version by default.

Olivier



> With the latest version we also released the build tools that allow compiling
> ONLYOFFICE Desktop Editors from source code. Here
> *https://helpcenter.onlyoffice.com/desktop/documents/linux/compile-desktop.aspx*
> 
> you will find an example of compiling the source code for Ubuntu 14.04.
> You can adapt this instruction and compile the source code for any Linux
> OS.
>
> *Why users choose ONLYOFFICE desktop app**?*
>
> *1 pack - 3 editors**.* Users can view, create and edit text documents,
> spreadsheets and presentations of any size and complexity.
>
> *H**igh compatibility with* *Office Open XML**. *OOXML is used as a core
> format which guarantees highest compatibility with DOCX, XLSX, and PPTX.
> Other popular formats such as ODF, CSV, PDF, RTF, TXT, etc. are also
> supported.
>
> *Quick c**onnection to the cloud*. Users are able to connect the editors
> to the cloud of their choice (ONLYOFFICE cloud, Nextcloud, ownCloud) and 
> collaborate
> on docs using real-time and paragraph-locking co-editing modes, track
> changes, comments, built-in chat.
>
> *Familiar** intuitive interface*.* ONLYOFFICE has familiar interface with
> tools grouped into tabs. Users can work with several files within one and
> the same window switching between them, as well as drag-and-drop documents
> to open them in separate windows.
>
> available in 11 languages: English, French, German, **Italian**,
> Spanish, **Russian, **Czech, **Slovak**, **Polish, **Portuguese -
> Brazilian, **Chinese - Simplified**.*
>
> *Rich functionality. *Full set of editing and formatting tools, macros, 
> implementing
> extra functionality with the pre-installed plugins, e.g. Highlight code,
> Translator, Thesaurus, a plugin that allows sending docs as mail
> attachments right from the editor, etc. Open API allows creating and
> adding own plugins.
>
> So, will you be interested in adding ONLYOFFICE Desktop Editors to
> the Debian system so that lots of users get one more office suite option 
> highly
> compatible with OOXML formats and giving access to cloud collaboration?
>
> Useful links for you:
>
> - Official project page: *https://www.onlyoffice.com/desktop.aspx*
> 
>
> - GitHub: *https://github.com/ONLYOFFICE/DesktopEditors*
> 
>
> Please feel free to contact me if you need any further info. I would be
> really glad to get your feedback! Thanks!
>
> Best regards,
>
> Kseniya Fedoruk
>
> Marketing Communications Manager
>
> ONLYOFFICE Team
>
> 
>
> *e-mail: **kseniya.fedo...@onlyoffice.com*
> 
>
> *W: **www.onlyoffice.com*
> 
>

Re: Please do not drop Python 2 modules

[olivier sallou]

Le sam. 21 avr. 2018 20:04, Chris Lamb  a écrit :

> Adrian Bunk wrote:
>
> > The tip of the iceberg are some recent cases where Python 2 modules
> > were dropped that still had reverse dependencies in unstable
>
> I suspect developers may be reading too much into Lintian output,
> reading them as "Please remove your Python 2.x module".
>
> The motivating behind these tags were to prevent new Python 2.x
> packages being added to the archive (due to habit if anything
> else!) unless they were needed or requested, of course.
>

Indeed, python 2 modules are not forbidden, but NEW packages are *expected*
to provide python 3 plus optionally python 2 support, not python 2 only.
But good reasons would allow package to be accepted anyway.
I think that warning is really to hint users to go to python 3 which should
be default now

Olivier

>
> Suggestions for rewording gratefully received.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>
>

Re: Please do not drop Python 2 modules

[olivier sallou]

Le mer. 25 avr. 2018 01:54, Nicholas D Steeves  a
écrit :

> On Tue, Apr 24, 2018 at 12:29:54AM +0200, Thomas Goirand wrote:
> > On 04/21/2018 11:19 PM, Scott Kitterman wrote:
> > > Since we are supporting Python2 in the next release, there is no
> value> in dumping python-* packages now. Unlike many areas of the archive,
> > > Python packages are actively used by third-party code that isn't and
> > > won't be in Debian.
> >
> > There's always value to start de-crufting legacy stuff early. That being
> > said, I hear your message: this is breaking 3rd party code, and we need
> > to keep this in mind.
> >
> > > I'm generally in favor of getting rid of old stuff, but python2 isn't
> > > there yet.
> >
> > Right. But I do believe we need to be very careful to not send a wrong
> > message to our users. Debian deprecating Python 2 is good. A strong,
> > bold deprecation message is needed, even if we want to continue
> > supporting Python 2 for a bit more.
>
> At what stage should Python IDEs uploaded to NEW disable or not
> install Python 2 support?  Now?
>
> Should Python 2-specific IDEs and/or Python 2-specific educational
> materials be removed from the archive?  If so, then when?
>
> Andreas, I've CCed you because we've been in touch in the past, and
> because I have friends who do graduate work in bioinformatics on
> Debian systems.  With the upcoming end of Python 2 in Debian, what can
> we do to avoid losing them to CentOS?  Also, if appropriate and if it
> wouldn't be too much work, does Debian have a role in encouraging
> new masters and PhD candidates to choose Python 3?
>

I do not see your point here. Regarding education, using python 2 or 3
should be transparent. The matter is only to have the expected
programs/libraries available in python3. The only issue would be for
students not to have their favorite program available.
Anyway, py2 will not be supported anymore at some time...
Olivier



> Sincerely,
> Nicholas
>

Bug#829565: ITP: python-dictobj -- python library to access dictionary keys as instance attributes

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: python-dictobj
  Version : 0.4
  Upstream Author : William Grim
* URL : https://github.com/grimwm/py-dictobj
* License : Apache 2.0
  Programming Lang: Python
  Description : python library to access dictionary keys as instance 
attributes

This package extends the functionality of the normal Python dictionary by 
affording the ability to lookup dictionary keys as instance attributes (i.e. 
__getattr__) instead of "indices" (i.e. __getitem__).
This package is a dependency for Galaxy.