Bug#855600: src:nlopt: Please provide binary package for cxx library

[Afif Elghraoui]

Package: src:nlopt
Version: 2.4.2+dfsg-2
Severity: wishlist
Control: block 855597 by -1

Hello,

I'm looking to package phyx, but it depends on the C++ version of the nlopt 
library.
While libnlopt-dev provides both the C and the C++ headers, the compiled
library only works for C++. We need separate packages for the C++ library.

I wouldn't mind making this change for you. Just let me know. I will need
it in order to continue packaging phyx (ITP set as a blocked by this).

Many thanks and regards
Afif

Bug#855597: ITP: phyx -- phylogenetic analyses on trees and sequences for UNIX

[Afif Elghraoui]

Hi, Andreas,

على الإثنين 20 شباط 2017 ‫08:26، كتب Andreas Tille:
> Hi Afif
> 
> On Mon, Feb 20, 2017 at 08:14:30AM -0800, Afif Elghraoui wrote:
>>   Description : phylogenetic analyses on trees and sequences for UNIX
> 
> Please drop " for UNIX" here - since this is redundant on a Debian system.
> May be
> 
>s/ for UNIX/ at command line enabling pipes/
> 
> or something like this makes the specific features of the tools more clear.
>  

Thanks for your comment; I was myself unsure about the wording. However,
this was meant to emphasize the nature of the tools in following the
UNIX style, but your suggestion is a bit wordy.

How about "UNIX-style phylogenetic analyses on trees and sequences"?

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#855597: ITP: phyx -- phylogenetic analyses on trees and sequences for UNIX

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

* Package name: phyx
  Version : 0.99
  Upstream Author : Joseph W. Brown, Joseph F. Walker, and Stephen A. Smith
* URL : https://github.com/FePhyFoFum/phyx
* License : GPL
  Programming Lang: C++
  Description : phylogenetic analyses on trees and sequences for UNIX

 phyx provides a convenient, lightweight and inclusive toolkit consisting of
 programs spanning the wide breadth of programs utilized by researchers
 performing phylogenomic analyses. Modeled after Unix/GNU/Linux command
 line tools, individual programs perform a single task and operate on
 standard I/O streams. A result of this stream-centric approach is that, for
 most programs, only a single sequence or tree is in memory at any moment.
 Thus, large datasets can be processed with minimal memory requirements.
 phyx’s ever-growing complement of programs consists of over 35 programs
 focused on exploring, manipulating, analyzing and simulating phylogenetic
 objects (alignments, trees and MCMC logs). As with standard Unix command
 line tools, these programs can be piped (together with non-phyx tools),
 allowing the easy construction of efficient analytical pipelines.


This package will be maintained by the Debian Med team.

Bug#852970: RM: pbcopper/0.0.1+20161202-2

[Afif Elghraoui]

على السبت 28 كانون الثاني 2017 ‫07:45، كتب Simon McVittie:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> X-Debbugs-Cc: Afif Elghraoui <a...@debian.org>
> 
> Afif Elghraoui wrote:
>> There is nothing actually wrong with pbcopper, but there is no sense in
>> releasing this package for stretch since it basically only exists to
>> support unanimity, which did not make the cutoff.
> I think the hint for this would be:
> 
> # RoM, #852654
> remove pbcopper/0.0.1+20161202-2

Sure. Just as long as it's removed from Testing and not from Unstable.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#852654: src:pbcopper: no point to releasing it without `unanimity`

[Afif Elghraoui]

Package: src:pbcopper
Version: 0.0.1+20161202-2
Severity: important

There is nothing actually wrong with pbcopper, but there is no sense in
releasing this package for stretch since it basically only exists to
support unanimity, which did not make the cutoff.

--
Afif Elghraoui

Bug#639910: ITP: simple-build-tool -- bootstrapping

[Afif Elghraoui]

Hello,

There was a bioinformatics program I was considering packaging, but it
requires sbt to build and so I came across this ITP. I just have a
couple of comments on this bootstrapping situation.

On Sun, 05 Feb 2012 20:29:09 +0100 Mehdi Dogguy <me...@dogguy.org> wrote:
> On 05/02/12 18:35, Josh Suereth wrote:
> > As I stated before, I feel requiring SBT to build without itself is
> > like trying to build Debian without GCC.
> 
> Comparing this situation to "trying to build _gcc_ without _gcc_" would
> be a more fair comparison. (imho)
> 

I think it is actually more like trying to build `make` without `make`.
In fact, GNU make provides a shell script to build `make` if you don't
have an existing version to use [1], so it seems like a fair approach to
take here. I don't think the sbt developers should consider it offensive
to do so.

Bootstrapping a compiler is necessary to otherwise avoid doing manual
work. The alternative to bootstrapping a build tool is not manual work,
but a different, maybe less efficient but still automatic approach.

Thanks and regards
Afif


1. http://git.savannah.gnu.org/cgit/make.git/tree/build.template

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849265: user-setup: hardware access groups should not be default

[Afif Elghraoui]

Hello,

I had #849265 reported against adduser for this problem that exists in
d-i's user-setup. It also exists in adduser if the --add_extra_groups
flags is used (which is why I didn't reassign/merge), user-setup is
adding this groups directly.

See the bug log for 849265 [1], as well as my correspondence with
pkg-systemd [2].

Thanks and regards
Afif

1. http://bugs.debian.org/849265
2.
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2017-January/013684.html

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849619: python-networkx: agressive use of Recommends

[Afif Elghraoui]

On السبت  7 كانون الثاني 2017 15:17, Sandro Tosi wrote:

On Sat, Jan 7, 2017 at 5:34 PM, Afif Elghraoui <a...@debian.org> wrote:

I hope what I've said now convinces you



sadly you didnt



What is it that doesn't make sense to you? Is it that you don't agree 
that the current situation violates policy or that you just don't want 
to change it?


The specific case in which I discovered this problem is that installing 
pbhoney gets all of networkx's unnecessary recommends. If you do 
no-install-recommends to avoid the unnecessary recommends, you don't get 
pbhoney's legitimate recommends of pbdagcon and unnecessarily use the 
inferior built-in fallback implementation.


If I made pbdagcon a hard dependency, then you would not be able to 
install pbhoney in a situation where pbdagcon isn't available without 
making a dummy package using equivs.


What functionality of *networkx* is affected when its recommends are not 
installed? If the answer is nothing, which it seems to be, then they 
definitely don't belong in recommends.


regards
Afif

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849619: python-networkx: agressive use of Recommends

[Afif Elghraoui]

On الجمعـة  6 كانون الثاني 2017 12:34, Sandro Tosi wrote:

On Wed, Dec 28, 2016 at 10:28 PM, Afif Elghraoui <a...@debian.org> wrote:

There are many valid use cases of networkx on headless systems or where
visualization is done by other, separate programs, possibly written in
different languages where these currently recommended packages are not needed.


i consider the ability to generate graphical visualization of a graph
an important feature (not a core one), that's why those packages (all
required for visualization) are in Recommends.  If you dont like them,
you can apt remove them or dont install recommends at all,but you are
not providing strong indication we should change this behavior


I think it's enough to reiterate the policy for Recommends, especially 
the part that says "This declares a strong, but not absolute, 
*dependency*", which is the reason why apt installs them by default. The 
things you have in Recommends now are not any kind of dependency at all. 
People who like to always get useful extras can install suggests.


To give an example of an appropriate Recommends situation, I have a 
package, pbhoney that uses pbdagcon, but has a fallback implementation 
in case pbdagcon is not available. I therefore put pbdagcon as a 
Recommends. pbhoney's fallback implementation should only be used if 
pbdagcon isn't available, like on some architectures. If people have to 
keep disabling Recommends to avoid installing things that should be 
Suggests, they will have a somewhat crippled installation here.



(which
has been there since ~10 years).



I don't think this makes it more correct. The misuse of Recommends has 
been discussed before. See 
https://lists.debian.org/debian-devel/2016/04/msg00159.html and the rest 
of the thread.


I hope what I've said now convinces you. Thanks for working on these 
packages in any case.


regards
Afif

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#850227: singularity-container: homepage URL link is broken

[Afif Elghraoui]

Package: src:singularity-container
Version: 2.2-1
Severity: minor

Hello,

The homepage URL is a dead link. I believe you want 
.

I haven't checked the source URL or d/watch, but that might be bad as well.
The source is at .
You're good on the latest upstream release according to that, though.

Thanks and regards
Afif

Bug#849265: [Adduser-devel] Bug#849265: adduser: Should not add users to the audio group

[Afif Elghraoui]

Hi,

على الأربعاء 28 كانون الأول 2016 ‫14:36، كتب Dan Keast:
> Hi Afif,
> 
> That sounds like a great idea to me.
> 
> It's a pretty trivial change, but I've attached a patch file if it's of
> any use to you.
> 

Thanks for the patch. Anyway, I've just gotten around to contacting the
udev maintainers:

http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2017-January/013683.html

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849498: cme: Please allow "fixing" without restyling

[Afif Elghraoui]

Control: tag -1 + help

Hello,

على الأربعاء 28 كانون الأول 2016 ‫02:03، كتب Dominique Dumont:
> On Tuesday, 27 December 2016 13:51:28 CET you wrote:
>> For the case of team uploads (and maybe NMU's) where people like to use cme
>> to fix certain issues in debian/control, it would be helpful if calling cme
>> fix would *only* fix issues and not restyle it. 
> 
> I've tried such a way by bridging Config::Model with Augeas [1] [2]. But 
> supporting
> such a solution is too much work for the benefit. 
> 
> I may reconsider this if I get help hacking on Config::Model.
> 

I've added the 'help' tag to reflect this.

>> If the primary maintainer
>> is not using cme, the uploader would have to either not use cme in this
>> case or take care to commit only the necessary changes, which adds extra
>> work and disrupts the uploader's workflow. 
> 
> You forgot one option: ask the primary maintainer to accept once a
> re-ordering imposing by cme. This would minimize the impact of further
> changes done by cme. 
> 
> Mentioning that cme's style matches the ordering of parameters in Debian 
> policy may help convincing the primary maintainer.
> 

I am one such maintainer. While I can get used to a field ordering
different from that used by dh-make, my main problem is the way cme
organizes lists-- it removes trailing commas and doesn't use a constant
indentation level globally. Trying to maintain this isn't a one-time
fight with cme.

Thanks and regards
Afif

> 
> [1] http://augeas.net/docs/references/1.4.0/lenses/files/debctrl-aug.html
> [2] 
> http://search.cpan.org/dist/Config-Model-Backend-Augeas/lib/Config/Model/Backend/Augeas.pm
> 

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849619: python-networkx: agressive use of Recommends

[Afif Elghraoui]

Package: python-networkx
Version: 1.11-2
Severity: normal

Hello,

I maintain and use some genomics packages that depend on this library,
but do not need some of the packages it Recommends.
I think some of the Recommends of this package should instead be Suggests.

I would say that at least python-matplotlib and python-pygraphviz/python-pydot
fall into this category, but please consider whether the others also really
need to be Recommends based on the defintions from policy:

~~~ 
Recommends

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found together with 
this one in all but unusual installations.

Suggests

This is used to declare that one package may be more useful with one or 
more others. Using this field tells the packaging system and the user that the 
listed packages are related to this one and can perhaps enhance its usefulness, 
but that installing this one without them is perfectly reasonable.
~~~

There are many valid use cases of networkx on headless systems or where
visualization is done by other, separate programs, possibly written in
different languages where these currently recommended packages are not needed.

Many thanks and regards
Afif

Bug#849500: libconfig-model-dpkg-perl: improper handling of comments

[Afif Elghraoui]

على الأربعاء 28 كانون الأول 2016 ‫01:44، كتب Dominique Dumont:
> On Tuesday, 27 December 2016 13:59:40 CET you wrote:
>> I'm not a cme user, but I've seen as part of team uploads in my packages
>> before that comments in debian/control are moved away from the lines
>> they refer to in the process of reorganization (and inadvertently committed
>> without being checked).
> 
> Could you provide an example of such a control file ?

See:
https://anonscm.debian.org/git/debian-med/python-bx.git/tree/debian/control

Here is an example of an inadvertent commit of changes:

https://anonscm.debian.org/git/debian-med/canu.git/commit/?id=fb82bd7c6e4d1462ec1bf22747ab61107c6e73d3

> 
>>  cme does not handle comments properly: either their relative position
>> to the lines they refer to should be preserved, 
> 
> I'll see what I can do.
> 
>> or they should be removed
>> altogether.
> 
> I can certainly add an option to cme to remove comments. Would that be 
> helpful?

Well, not to me. I'm of the opinion that if the debian/control format
supports comments, other tools shouldn't consider them illegal.

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#832391: consensuscore2: figured out the resolution

[Afif Elghraoui]

While this package was removed from unstable in favor of unanimity
(which didn't get processed in time to be considered as part of the
release of Stretch), I figured out the solution to this RC bug, as
unanimity was showing similar issues.

I didn't realize that pybuild itself does build-system detection and its
detection is not reproducible when there is more than one possibility.
In this case, when it detects "distutils", the build works. When it
detects "cmake", the package comes out empty. The solution (and what was
done for unanimity) was to explicitly set it to "distutils".

Just posting here for the record in case someone else stumbles across a
similar issue.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849500: libconfig-model-dpkg-perl: improper handling of comments

[Afif Elghraoui]

Package: libconfig-model-dpkg-perl
Version: 2.087
Severity: normal

Hello,

I'm not a cme user, but I've seen as part of team uploads in my packages
before that comments in debian/control are moved away from the lines
they refer to in the process of reorganization (and inadvertently committed
without being checked).

In bringing this up, I was strongly opposed in that there is no reason for
there to be comments in debian/control. Regardless of the position taken on
this, cme does not handle comments properly: either their relative position
to the lines they refer to should be preserved, or they should be removed
altogether.

Many thanks and regards
Afif

Bug#849498: cme: Please allow "fixing" without restyling

[Afif Elghraoui]

Package: cme
Version: 1.016-1
Severity: wishlist

Hello,

For the case of team uploads (and maybe NMU's) where people like to use cme to
fix certain issues in debian/control, it would be helpful if calling cme fix
would *only* fix issues and not restyle it. If the primary maintainer is
not using cme, the uploader would have to either not use cme in this case or
take care to commit only the necessary changes, which adds extra work and
disrupts the uploader's workflow. It would be great if `cme fix` only fixed
and there was another command that would do this in addition to
restyling/reorganizing the files.

Many thanks for your consideration.

regards
Afif

Bug#849265: [Adduser-devel] Bug#849265: adduser: Should not add users to the audio group

[Afif Elghraoui]

Hello and thanks for the report

على السبت 24 كانون الأول 2016 ‫03:52، كتب Daniel Keast:
> 
> I was having issues with fast user switching in Gnome. When the first user
> leaves something running that uses the sound card the second user only gets a
> "Dummy Output" sound device. Researching the problem led me to find that users
> should not be in the 'audio' group but all of the users on my systems were:
> 
> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/
> 
> https://wiki.ubuntu.com/Audio/TheAudioGroup
> 
> https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#User_privileges
> 
> Removing the users from this group fixes the issue completely. I'm not sure
> what package creates users during installation, but the --add_extra_groups 
> flag
> for this command adds this group.
> 

I'd like to get in touch with the udev maintainers about this. There may
be other groups in this set of extra_groups that are in a similar situation.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849431: [Debian-med-packaging] Bug#849431: daligner: FTBFS with ld --as-needed

[Afif Elghraoui]

Hi, Logan,

على الإثنين 26 كانون الأول 2016 ‫20:55، كتب Logan Rosen:
> daligner 1.0+20160927-1 fails to build in Ubuntu because the lddflags.patch 
> adds libraries
> to the linker options (LDFLAGS) instead of where library flags should be 
> placed, at the end
> (in LDLIBS).

That was my ignorance. Thanks for correcting it.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#844034: Any intend to fix this soon

[Afif Elghraoui]

Hi, Andreas,

على السبت 24 كانون الأول 2016 ‫11:34، كتب Andreas Tille:
> On Sat, Dec 24, 2016 at 07:24:22AM -0800, Afif Elghraoui wrote:
>> I'm really sad to see the duplication of effort when I was so
>> particular to make sure my work was pushed :(. Is there a way we can
>> avoid this in the future?
> 
> Its no real problem.  I think it will not happen to frequently since the
> situation to save package for upcoming releases is only every second
> year - perhaps posting the fact you are working in a separate branch
> would help in such cases.

Fair enough. I thought it might have been sufficient to post updates to
the upstream tracker since the bug was marked as forwarded.

>  Feel free to replace everything I did by your
> probably more advanced changes since you know the internals way better.
> I also do not consider my time terribly wasted since I now have some
> insight into these packages.
> 

Thanks.

As a quick update (also posted to the upstream tracker), some changes in
blasr 5's handling of SAM/BAM files is causing the main problems now.
Fixing it in pbhoney would require some more intrusive changes, which I
could probably handle, but I don't think it would be a good idea to
proceed without upstream's cooperation on this. It's possible that
pbsuite will not be released with Stretch because of this.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#844034: Any intend to fix this soon

[Afif Elghraoui]

Hi, Andreas,

على السبت 24 كانون الأول 2016 ‫01:30، كتب Andreas Tille:
> Hi Afif,
> 
> pbhoney is marked for autoremoval due to this bug.  I'm guessing from
> the description of the problem that it should be easy to fix (without
> having checked).  Do you intend to upload soon or should somebody
> else step in here?
> 

I have actually been working on this over the past few days. I keep
works-in-progress out of the master branch, so my work is in the branch
topic/blasr-5 [1] and I've been posting updates to the upstream bug
tracker to avoid duplication of efforts between here and upstream. I
hoped anyone taking a look here would first check the upstream bug
tracker. I'm really sad to see the duplication of effort when I was so
particular to make sure my work was pushed :(. Is there a way we can
avoid this in the future?

The reason I made a blasr upload yesterday was because I was advised
that it might fix a problem that was affecting pbhoney (after correcting
the command-line flags). I was going to continue testing today, now that
the upload has been installed in the archive, and report back to the
blasr upstream.

Thanks and regards
Afif

1. https://anonscm.debian.org/git/debian-med/pbsuite.git/log/?h=topic/blasr5

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849187: RM: kmer-tools -- ROM; superceded by kmer

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


The source package has been renamed, so this old source package should
be removed. I noticed that this doesn't happen automatically if the source
package is renamed without a change in the upstream version, which is the
case here.

Many thanks and regards
Afif

Bug#849186: RM: pbseqlib [i386 armel mipsel] -- ROM; new build-dependency not available

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal
Control: block -1 with 849183 849184

pbseqlib is now built with pbbam, which is not available on 32-bit
architectures. I've also filed for removal of the reverse-dependencies on
these architectures for the same reason (see blocking bugs).

Many thanks and regards
Afif

Bug#849184: RM: pbdagcon [i386 armel mipsel] -- ROM; new build-dependency not available

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


pbdagcon (like blasr) has a new build-dependency on pbbam, which is not
available on 32-bit architectures.

Many thanks and regards
Afif

Bug#849183: RM: blasr [i386 armel mipsel] -- ROM; new build-dependency not available

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


blasr has a new build-dependency (pbbam) that is not available on 32-bit
architectures.

Many thanks and regards
Afif

Bug#832391: consensuscore2: Any news?

[Afif Elghraoui]

على الخميس 22 كانون الأول 2016 ‫00:55، كتب Afif Elghraoui:
> 
> I think it's
> a good time to have this package removed.
> 

FTR, I've just filed for its removal.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849057: RM: consensuscore2 -- ROM; superceded by unanimity

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


consensuscore2 has been moved to part of a larger project called
unanimity (#847310). I kept consensuscore2 around in the meantime since
unanimity hasn't been packaged yet, but the older version from there
has been found to be too buggy to pursue releasing it for stretch.

Thanks and regards
Afif

Bug#832391: consensuscore2: Any news?

[Afif Elghraoui]

على الأربعاء 21 كانون الأول 2016 ‫08:01، كتب Adrian Bunk:
> On Tue, Dec 06, 2016 at 11:19:02PM -0800, Afif Elghraoui wrote:
>> ...
>> I'd like to just be a little conservative with this. Indeed, if
>> everything goes well with unanimity, we will need to file for this
>> removal. I'd just rather that unanimity be assuredly packaged before
>> removing this one.
> 
> If consensuscore2 should be in stretch, you have to fix this bug in the 
> consensuscore2 source package pretty soon.
> 

Thanks for your concern. I recently reviewed upstream changelogs, and it
looks like this version of consensuscore2 had some important bugs that
were fixed in the new version that's included in unanimity now. Because
of this and because there's no clear way to separate consensuscore2 from
the unanimity code base to include in this source package, I think it's
a good time to have this package removed.

> A new unanimity package would be too late for stretch (it would have
> to be packages, uploaded and accepted no later than this weekend).
> 

I've been working on this behind the scenes. pbcopper, a
build-dependency for unanimity, was recently accepted. I think I'm also
close to having the unanimity package completed. It is either unanimity
or nothing.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#848542: src:kineticstools: new upstream version 0.6.1

[Afif Elghraoui]

على الإثنين 19 كانون الأول 2016 ‫12:07، كتب Diane Trout:
>>  
>> kineticstools can be updated, but it has a new dependency on
> pybigwig.
> 
> 
> In case the BTS doesn't automatically notify you, pybigwig was just
> accepted
> 

Many thanks for letting me know. The BTS didn't send any notification.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#848542: src:kineticstools: new upstream version 0.6.1

[Afif Elghraoui]

Package: src:kineticstools
Version: 0.5.2+dfsg-2
Severity: normal
Control: block -1 by 846663

kineticstools can be updated, but it has a new dependency on pybigwig.

Afif

Bug#848541: src:blasr: build with pbbam

[Afif Elghraoui]

Package: src:blasr
Version: 5.3-1
Severity: normal
Control: block 844034 by -1

I can't find a link for this right now, but I understand that the
`--sam` option to blasr cannot be used unless blasr is compiled
with pbbam.

pbsuite makes use of this `--sam` option, so in order for it to work with
the newer blasr version (#844034), this needs to be resolved.

I've just updated the pbseqlib package so that it is now built with pbbam.
Once that becomes available in unstable, building blasr with pbbam should
work.

regards
Afif

Bug#848122: ITP: pbcopper -- data structures, algorithms, and utilities for C++ applications

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
Control: block 847310 by -1

* Package name: pbcopper
  Version : 0.0.1
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/pbcopper
* License : BSD
  Programming Lang: C++
  Description : data structures, algorithms, and utilities for C++ 
applications

pbcopper provides general tools for C++ applications. It is developed
for use by applications of the Pacific Biosciences SMRT Analysis
suite.

This package is a dependency of unanimity. It will be maintained by the Debian 
Med team.

Bug#846770: gridengine: FTBFS: cc: error: libsched.a: No such file or directory

[Afif Elghraoui]

Control: tag -1 = confirmed

On الإثنين  5 كانون الأول 2016 01:09, Lucas Nussbaum wrote:
>> I have just tried a parallel build on an up-to-date unstable chroot on
>> > amd64 and it builds just fine for me. Can you confirm?
> No, it still fails for me.
>
> However, it build fine with DEB_BUILD_OPTIONS=parallel=1. So I suspected
> that it fails due to missing dependencies in some makefile.
>
> You can try with e.g. DEB_BUILD_OPTIONS=parallel=64 to see if you
> reproduce it.

I can reproduce it if I try 64 threads, but I've always built with 12
threads without any trouble. Here is the error, untangled from parallelism.

cc -o pdc -L. -Wl,-z,relro -rdynamic
-Wl,-rpath,\$ORIGIN/../../lib/lx-amd64  pdc_main.o procfs_main.o
libsched.a libsgeobj.a libcomm.a libcommlists.a libsgeobjd.a libcull.a
libuti.a libuti2.a  -luti -ldl -lmunge -lssl -lcrypto  -lm -lpthread
-ljemalloc -lmunge
cc: error: libsched.a: No such file or directory
../daemons/common/Makefile:94: recipe for target 'pdc' failed
make[2]: *** [pdc] Error 1

so yes, libsched.a needs to be declared as a prerequisite of pdc.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#832391: consensuscore2: Any news?

[Afif Elghraoui]

على الثلاثاء  6 كانون الأول 2016 ‫08:48، كتب Andreas Tille:
> Whoops, do you want me to reassign the bug back from ftp.debian.org to 
> consensuscore2?
> Or, before you simply answer it is may be faster if you do the reassigning 
> yourself (except if that's to cumbersome from your phone ...).

Thanks for handling this.


> Sorry if I totally missinterpreted the discussion. :-(

I'd like to just be a little conservative with this. Indeed, if
everything goes well with unanimity, we will need to file for this
removal. I'd just rather that unanimity be assuredly packaged before
removing this one.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#847310: RFP: unanimity -- generate and process accurate genomic consensus sequences from single-molecule sequencing data

[Afif Elghraoui]

Package: wnpp
Severity: wishlist

* Package name: unanimity
  Version : 2.0.4
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/unanimity
* License : BSD
  Programming Lang: C++, Python
  Description : generate and process accurate genomic consensus sequences 
from single-molecule sequencing data

This package provides a common source for the related consensus processing
modules pbccs (for circular consensus sequencing), and the algorithms library
consensuscore2.

The consensuscore2 source package would be superceded by this one. pbccs hasn't
been packaged for Debian before, but would be newly provided by this unanimity
package.

Rudimentary packaging has been posted in the Debian Med team at
.
Anyone interested in helping with this should contact the Debian Med team 
.

Thanks and regards
Afif

Bug#832391: consensuscore2: Any news?

[Afif Elghraoui]

على الثلاثاء  6 كانون الأول 2016 ‫06:48، كتب Andreas Tille:
> So I wonder whether we should turn this into an ITP unanimity[1].

I made a RFP for this with Cc to debian-med-packaging. The bug number
hasn't been issued yet, so I don't have a BTS link to post here.

>  The
> first stumbling stone is that they do not add release tags but have
> somehow switched of reporting this as an issue on Github (at least I
> can't find any contact to ask them for tags :-().

I've asked several times and they won't provide them for most of their
projects. From my experience, they also don't accept patches for
enhancements. The only support that can be expected from them is for
anything that aligns with their interests. Aside from whatever build
instructions are described in the repository, some hints for packaging
might be found in upstream's source integration builder:
<https://github.com/PacificBiosciences/pitchfork>

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#832391: consensuscore2: Any news?

[Afif Elghraoui]

Whoa, wait a minute. Consensuscore2 hasn't been deprecated yet--it's just been 
bundled with other things in the unanimity suite.
The reason I don't support removal of this source package is that we might find 
the best solution to be extracting consensuscore2 from unanimity and using that 
for the orig tarball here. We will likely run into fhe same or worse problems 
trying to package everything from one unanimity source package.
I can elaborate when I get off work, but please do not remove this source 
package.
Afif
Sent from my T-Mobile 4G LTE Device Original message From: 
Andreas Tille  Date: 12/6/2016  06:48  (GMT-08:00) To: 
Ghislain Vaillant , 832...@bugs.debian.org Cc: Debian Med 
Project List  Subject: Re: Bug#832391: 
consensuscore2: Any news? 
Hi,

On Tue, Dec 06, 2016 at 11:23:36AM +, Ghislain Vaillant wrote:
> > 
> > I should have posted an update. Upstream has moved consensuscore2 into a
> > new source package, unanimity [1]. The packaging issues I was having are
> > due to building the mixed-language code base. I have not found a good
> > solution for this with debhelper, and the upstream build system was also
> > very unconventional in order to handle it (which did not help
> > debhelper's latching onto it). I think what needs to be done is to just
> > package unanimity and have consensuscore2 be one of its binary packages.
> > I'll have to see whether this problem will come up again after that.
> 
> I confirm Afif's reporting. This project is deprecated in favour of a larger
> one.
> 
> We should just request an RM for this package, since we won't be getting any
> support for it from upstream in the future, and focus on the new project. This
> should also clear the current RC bug affecting it.

So I wonder whether we should turn this into an ITP unanimity[1].  The
first stumbling stone is that they do not add release tags but have
somehow switched of reporting this as an issue on Github (at least I
can't find any contact to ask them for tags :-().

I'm personally fine with removing consensuscore2 package from Debian.

Afif, could you push your preliminary work how rudimentary / non-working
it might be?  It just helps to display the current state on the tasks
pages as prospective package in VCS (in case somebody is seeking for an
interesting job ...)

Kind regards

   Andreas.

PS: I'll reassign #832391 to ftp.debian.org and turn it into a ROM request.

[1] https://github.com/PacificBiosciences/unanimity

-- 
http://fam-tille.de

Bug#847013: src:libsbml: build python3 bindings

[Afif Elghraoui]

Package: src:libsbml
Version: 5.12.0+dfsg-3
Severity: wishlist

The package currently builds only python2 bindings, but it would be nice to
build them for both python2 and python3.

I briefly looked into this, but it looks like it will not be quick to do.

regards
Afif

Bug#846770: gridengine: FTBFS: cc: error: libsched.a: No such file or directory

[Afif Elghraoui]

Control: tag -1 + moreinfo unreproducible

Hello,

على السبت  3 كانون الأول 2016 ‫00:46، كتب Lucas Nussbaum:
> Source: gridengine
> Version: 8.1.9+dfsg-3
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161202 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
>> cc -o qmod -L. -Wl,-z,relro -rdynamic -Wl,-rpath,\$ORIGIN/../../lib/lx-amd64 
>>  qmod.o sig_handlers.o usage.o sge_options.o -lgdi -lsgeobj -lsgeobjd -lcull 
>> -lcomm -lcommlists -luti  -lmunge -lssl -lcrypto  -luti -ldl  -lm -lpthread 
>> -ljemalloc -lmunge
>> cc: error: libsched.a: No such file or directory
>> cc -o qevent -L. -Wl,-z,relro -rdynamic 
>> -Wl,-rpath,\$ORIGIN/../../lib/lx-amd64  qevent.o  usage.o sig_handlers.o 
>> sge_options.o sge_mt_init.o -lmir -levc -lgdi -lsgeobj -lsgeobjd -lcull 
>> -lcomm -lcommlists -luti  -lmunge -lssl -lcrypto  -luti -ldl  -lm -lpthread 
>> -ljemalloc -lmunge
>> ../daemons/common/Makefile:94: recipe for target 'pdc' failed
>> make[2]: *** [pdc] Error 1
> 
> The full build log is available from:
>http://aws-logs.debian.net/2016/12/02/gridengine_8.1.9+dfsg-3_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
> 
I have just tried a parallel build on an up-to-date unstable chroot on
amd64 and it builds just fine for me. Can you confirm?

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#846045: python-pytest-benchmark: fixture is not detected by pytest

[Afif Elghraoui]

Package: python-pytest-benchmark
Version: 3.0.0-1
Severity: serious

Hello,

I am trying to run build-time tests for one of my packages where upstream
just switched to pytest. The benchmark module does not get loaded (as verified
by running `python2 -m pytest --traceconfig` after installing
python-pytest-benchmark), so the tests fail with the error "fixture
'benchmark' not found".

I see that the plugin for Python 3 does get detected, so the problem is
strangely specific to just the Python 2 version of the package (which is what
this bug report is for). I tested another packaged pytest module on Python 2,
python-pytest-django, and I see that it's detected properly. The problem
does not therefore seem to be with the Python 2 version of pytest.

Many thanks and regards
Afif

Bug#845791: [Adduser-devel] Bug#845791: adduser: /bin/false vs /usr/sbin/nologin

[Afif Elghraoui]

Control: tag -1 + confirmed

Hello,

على السبت 26 تشرين الثاني 2016 ‫10:14، كتب Olaf van der Spek:
> Package: adduser
> Version: 3.115
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Some system accounts use /bin/false, most use /usr/sbin/nologin as shell.

It looks like the ones created by base-passwd are the ones using
/usr/sbin/nologin.

> adduser --system defaults to /bin/false.. wouldn't it be nicer to default to 
> /usr/sbin/nologin?
> 

Yes.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#708073: adduser: Recreating a system user fails when its UID is out of range

[Afif Elghraoui]

Hello,

On Mon, 13 May 2013 00:12:45 +0200 Eduard Bloch <e...@gmx.de> wrote:
> clone 706382 -1
> retitle -1 Recreating a system user fails when its UID is out of range
> reassign -1 adduser
> severity -1 minor
> thanks
> 
> As discussed, the error handling in this case needs some improvement. As
> least there should be a meaningful error message telling where the
> error originated.
> 
> And/or it maybe should not be an error whatsoever, i.e. when the account
> exists then there is no need to recreate it.
> 

What happened in this case was that adduser was asked to add a system
user while the name is already taken by a *regular* user (maybe that is
the key word missing from the printed message), as determined by the
system UID range.

The system user range can be changed by the administrator in
/etc/adduser.conf if they want to use a different range to determine
what a system user is.

I'd appreciate any suggestions to make this more clear so this confusion
can be avoided in the future.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#521883: adduser: Please accept underscore prefixed system names

[Afif Elghraoui]

Control: tag -1 + confirmed

على الخميس 24 تشرين الثاني 2016 ‫16:30، كتب Guillem Jover:
>> I am also in favor of reducing unnecessary incompatibilities that can
>> > cause confusion. People of #432562, do you have any comments?
> At least Ian seemed to retract his previous support for Debian-style
> names in <https://lists.debian.org/debian-devel/2016/10/msg00577.html>,
> but I'll let him confirm this.
> 
> I also think allowing Debian-style names by default would be a bad
> idea, and I'm glad that bug is marked as wontfix. ;)

I thought that bug report was simply about using a capital letter
prefix, not necessarily [dD]ebian-* (especially since it was an
Ubuntu-proposed change). Anyway...

> 
> (You might also like to check the thread starting at
> <https://lists.debian.org/debian-devel/2016/10/msg00546.html>.)

Many thanks for these links. I've read through all of them, as well as
the much older threads and tickets that were linked from these discussions.

Since considering underscore-prefixed names as a valid format for system
user accounts does not necessarily mandate its use, I have no problem
accepting this. The campaign for making it the resolution of #248809 is
another matter.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#521883: adduser: Please accept underscore prefixed system names

[Afif Elghraoui]

Hello and apologies for the delay,

على الأحد 23 تشرين الأول 2016 ‫06:52، كتب Guillem Jover:
> Control: tags -1 patch
> Control: retitle -1 adduser: Please accept underscore prefixed system names
> 
[...]
> I've implemented a new SYS_NAME_REGEX so that at least system names
> can accept _-prefixed values. This is the standard used on various
> BSDs, it is vendor neutral (not just a Debianism), and it is short
> causing way less display problems.
> 
> I don't think accepting _-prefixed names for normal users would be
> wise, as that would remove the namespaced disctinction.
> 
> Having this in the archive would allow us to promote these system
> names, and use them w/o needing the --force-badname option!
> 

This is somewhat similar to #432562. The difference, as I see it, is
capital letters + compatibility with Ubuntu versus underscores +
compatibility with BSDs. I don't see that any of the breakage concerns
originally raised in #432562 apply to this suggestion.

I am also in favor of reducing unnecessary incompatibilities that can
cause confusion. People of #432562, do you have any comments?

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#828329: gridengine: staying with libssl1.0

[Afif Elghraoui]

Control: severity -1 important
Control: unblock 827061 by -1

This path of staying behind with openssl 1.0 was approved by the release
team [1]. openssl 1.1 support is not ready upstream and gridengine is
not expected to interfere with co-installed packages using openssl 1.1.

1. https://lists.debian.org/debian-release/2016/11/msg00573.html

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#828481: ori: staying with libssl1.0

[Afif Elghraoui]

Control: severity -1 important
Control: unblock 827061 by -1

This path of staying behind with openssl 1.0 was approved by the release
team [1]. Upstream has not moved on to openssl 1.1 and we aren't
equipped to make and test the required changes.

1. https://lists.debian.org/debian-release/2016/11/msg00573.html

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#795890: ori: limiting architectures to linux-any

[Afif Elghraoui]

Control: severity -1 wishlist

I'm lowering the severity of this bug since I'm removing kfreebsd and
hurd from the architecture list of the package. If anyone would like to
help upstream add support for them, that would fulfill this ticket and
I'd change ori back to architecture:any.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#634262: arpwatch-ng status

[Afif Elghraoui]

Hi, Florian,

على الإثنين 21 تشرين الثاني 2016 ‫01:22، كتب Florian Schlichting:
> in 2014 when I created the Debian git repo, I also created an
> 'upstream-ng' branch so I (or someone else - I never got to it) could
> step through the development of arpwatch-ng in a little more detail and
> decide if that's a better upstream to base the Debian package on. You
> can still find that branch on github:
> 
> https://github.com/fschlich/Debian-arpwatch/commits/upstream-ng
> 
> Feel free to make use of any of it and push it to the git.d.o repo's
> upstream branch if you see fit - I'm glad if it's of use to anybody!
> 
>> > * <http://freshmeat.net/projects/arpwatch-ng> redirects to
>> > <http://freecode.com/projects/arpwatch-ng>, and freecode is frozen since
>> > 2014[1]. It looks like the only way to contact upstream is to see
>> > whether freecode site support can help.
>> > 
>> > ...or fork the project again.
> I think the arpwatch-ng upstream is as dead as the arpwatch one. There
> are a few more repos and patches on github, but it doesn't look like
> anybody has stepped up to pick up the pieces. Still I think arpwatch
> continues to be useful, and if you find the time to look into the
> arpwatch-ng work and find it to be sensible, please go forth and upload
> a Debian package based on it!

Thanks for the information, but my interest in arpwatch was short-lived,
so I don't expect to be working on it. Your update might spark someone
else's interest, though, and it's good that it's now documented here.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#827061: transition: openssl - will both 1.0.x and 1.1.x be in Stretch?

[Afif Elghraoui]

Hi,

I'm maintaining two packages affected by this transition. So far, I've
just been monitoring the situation, as I share many of the concerns that
have been raised on -devel.

Is it an acceptable solution to instead build-depend on libbsl1.0-dev,
downgrade the severity of the FTBFS with 1.1.0 bug to important, and
unblock the transition by it?

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#829645: src:gtest: Cannot build against libgtest-dev with std=c++11

[Afif Elghraoui]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, Steve,

على السبت 19 تشرين الثاني 2016 ‫20:36، كتب Steve M. Robbins:
> On Mon, Jul 04, 2016 at 05:51:20PM -0700, Afif Elghraoui wrote: The
> googletest package has recently been updated to 1.8.0 and built
> with gcc 6.  So I expect this issue is gone, but I'd like you to
> test it and let me know because I can't easily reproduce it even
> with version 1.7.0-4.
> 

Oh, this must be because I've updated pbbam in the meantime and my
packaging might need some more adjustment in order to properly build
the tests.

>> I'm trying to enable tests for the pbbam package, but there is a 
>> compilation error that is triggered by simply including gtest.h:
> 
> I attempted to reproduce using the following file, but it succeeds 
> without error.
> 
> #include 
> 
> int main() { return 0; }
> 
> 
>> 
>> Line 43 of my file
>> /<>/tests/src/test_AlignmentPrinter.cpp has:
>> 
>> #include 
> 
> I am unable to compile tests/src/test_AlignmentPrinter.cpp; I get
> this error:
> 
> g++ --std=c++11 -c tests/src/test_AlignmentPrinter.cpp 
> tests/src/test_AlignmentPrinter.cpp:42:22: fatal error: TestData.h:
> No such file or directory #include "TestData.h"
> 

This is a header that's supposed to be created from TestData.h.in
during build. I'll have to look into that.

   ^
> compilation terminated.
> 
> 
> Can you let me know if the new package fixes this bug?
> 

I'm fine if you want to close the bug. I can't verify it right now due
to some unrelated stupid build problem that I don't have time to deal
with (CMake is trying to use -lpthreads instead of -lpthread).

Thanks and regards
Afif

- -- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYMgfMAAoJEFmyMG86+d3BeMIQAJtQB63IrNXncDugK7gullFg
6/LgkvUy+nyuaNdz9GUvmmnYOEiuw8mMO/mgSResNoxxccTNeyjcwInaz02uG8t9
G0/tikPehP15ix/OPaV8kbdB79zV1iP2BPWX/RSlIYugM07X6cV6ZKsMJDurav9T
OKs66u4+RF+vkLznvDqNwy6DXuDk3eRRORbnD253MFhIEkJleeOZ4R6/n9AfoJ/Q
NulV09amJR4w9COWAnrzF9cGtm4Mm0oyRyF0mNovusOzbivK6iLsJtY1hpji/ol1
MLc5mIAU4IcRlLue0XG9Y+jRrzOULYZqDMzwxYGkT5txzZylrLeMEt1IuV0qVc5k
evEEQhEHK4huNtCE7eIQ4dWU28Wp32+qHzfhHJvN44JM76e3Oo7IrL5PUGvoT14I
cqwc8BQSL4UBqcP9ahmLg4Duz1psaMZsW9xrdRBboAVA7gR1I5NCewKkrNCqCo9m
2AJIcHdLCR28yA62nmr3LavGYobIZk20y/dWWgxw5LXDmcCaMmbC2vcSxQRYKC9f
AexpjoFWPsmhKrYUmq1jf4snKqnz0bKXK9QL7hcRLGlz/5qb3YUKluz9+QisJVJq
CatD9IAsvClT6JTjvdngO0PKKUQPv9EKEXJkQn100YamXjCVU9RuqAfwzyUHaDaf
SPEhz5V5p69oT3SHY3vl
=pi15
-END PGP SIGNATURE-

Bug#828329: [Pkg-gridengine-devel] Bug#828329: forwarded to https://arc.liv.ac.uk/trac/SGE/ticket/1572

[Afif Elghraoui]

Hi, Mark,

على الأحد 20 تشرين الثاني 2016 ‫08:12، كتب Mark Hymers:
> I've attached a patch in the upstream tracker to compile against OpenSSL
> 1.1.  The alternative would be to Build-Depend on openssl 1.0 for now
> (which looks like it will be allowable for jessie) as gridengine doesn't
> seem to expose any SSL implementation details to/from other libraries.
> 

Many thanks for working on this. I'd like to see what Dave says
upstream. Otherwise, I'd rather stick with 1.0 if possible. I need to
ask the release team if that's ok. So far, I've just been monitoring the
transition hubbub on -devel to see what's going to happen.

> I'm happy to prepare/upload a version with either fix in, depending on
> preference.

I can take care of it. I think there were a couple other simple bugs
that need to be fixed and now's a good time for that.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#634262: arpwatch-ng status

[Afif Elghraoui]

Control: retitle -1 arpwatch: base packaging on arpwatch-ng sources

(Cc'ing people who were previously in contact on this ticket)

I'm not sure if anyone else might care about this, but I started looking
into the arpwatch situation. Here is what I've found out:

* The site for arpwatch-ng (<http://freequaos.host.sk/arpwatch>) is
down. I was able to find a snapshot of it from earlier this year
(3/2016) at archive.org:

http://web.archive.org/web/20160321213852/http://freequaos.host.sk/arpwatch/

* From the above link, I was able to download the latest release, 1.7.

* In the README, this is the extent of the contact information:

~~~
If you have suggestions or patches, please use freshmeat.net to locate the
project and then use "contact developer". Only there a recent and working
email address is published.
DO NOT PUBLISH MY EMAIL ADDRESS ANYWHERE - IS SUBJECT TO CHANGE.

Thank you.

-Freek/2005
~~~

* <http://freshmeat.net/projects/arpwatch-ng> redirects to
<http://freecode.com/projects/arpwatch-ng>, and freecode is frozen since
2014[1]. It looks like the only way to contact upstream is to see
whether freecode site support can help.

...or fork the project again.

Anyway, I'm not sure if anyone is interested in pursuing this, but I
thought I should post the research I've just done in case it turns out
to be useful.

1. http://freecode.com/about

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#844377: fai-client: Please allow installing packages with apt's -t option

[Afif Elghraoui]

Package: fai-client
Version: 5.2
Severity: wishlist

The FAI guide says the following about pulling in packages from a
non-default release:

~~~
If you like to install packages from another release than the default, you
can append the release name to the package name like in
openoffice.org/etch-backports. You can also specify a certain version like
apt=0.3.1
~~~

However, it is often necessary to get a package and at least some of its
available dependencies from backports, and it is not practical to have
to track and specify each one to allow the minimum required version to
be pulled in. In such cases, there is a significant difference between

  aptitude -t jessie-backports install 

and

  aptitude install /jessie-backports


Would it be possible to add an option similar to how there is
aptitude-r, or a
way to add options to the package installation command line that would allow
users to specify them for a certain set of packages?

Many thanks and regards
Afif

-- 
Afif Elghraoui
Laboratory for Pathogenesis of Clinical Drug Resistance and Persistence
San Diego State University
Alvarado Medical Center
6367 Alvarado Court, Suite 206
San Diego, CA 92120
p. 858-222-0454
http://tuberculosis.sdsu.edu

Bug#844034: pbhoney: incompatible with blasr 5.x

[Afif Elghraoui]

Package: pbhoney
Version: 15.8.24+dfsg-1
Severity: serious
Control: forwarded -1 https://sourceforge.net/p/pb-jelly/tickets/5/

As blasr has been updated to 5.x in Unstable/Testing, pbhoney no longer works
due to the interface change there. blasr options in 5.x have been changed from
single dashes to double dashes.

pbhoney test log [1]:
~~~
2016-11-11 21:16:47,957 [INFO] Running /usr/bin/Honey pie 
filtered_subreads.fastq lambda_modified.fasta -o mappingFinal.sam
2016-11-11 21:16:47,957 [INFO] Running Blasr
2016-11-11 21:16:47,965 [ERROR] blasr mapping failed!
2016-11-11 21:16:47,965 [ERROR] RETCODE 1
2016-11-11 21:16:47,965 [ERROR] STDOUTOptions for blasr 
   Basic usage: 'blasr reads.{bam|fasta|bax.h5|fofn} genome.fasta [-options] 
 option Description (default_value).
~~~

1.https://ci.debian.net/data/packages/unstable/amd64/p/pbsuite/2016_211518.autopkgtest.log.gz

Bug#832391: consensuscore2: Any news?

[Afif Elghraoui]

Hi, Andreas,

على الأربعاء  9 تشرين الثاني 2016 ‫03:11، كتب Andreas Tille:
> 
> do you have any news with this issue?
> 

I should have posted an update. Upstream has moved consensuscore2 into a
new source package, unanimity [1]. The packaging issues I was having are
due to building the mixed-language code base. I have not found a good
solution for this with debhelper, and the upstream build system was also
very unconventional in order to handle it (which did not help
debhelper's latching onto it). I think what needs to be done is to just
package unanimity and have consensuscore2 be one of its binary packages.
I'll have to see whether this problem will come up again after that.

regards
Afif

1. https://github.com/PacificBiosciences/unanimity

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#819617: [Debian-med-packaging] Bug#819617: Bug#819617: bcftools: FTBFS: test suite fails on several architectures

[Afif Elghraoui]

على الجمعـة 28 تشرين الأول 2016 ‫00:51، كتب Afif Elghraoui:
> Hi, Andreas,
> 
> على الجمعـة 28 تشرين الأول 2016 ‫00:18، كتب Andreas Tille:
>>
>> Any other volunteer?  I think if the problem persists until our advent
>> bug squashing party I'll ask for removal of the packages for the
>> affected architectures. 
>>
> 
> We'd need a new source package, not just a new binary package for the
> pysam source code. I think you can expect for this bug not to be
> resolved soon, so I see that it is either the pysam source-package copy
> or the removal of rdeps on i386.

Come to think of it, this might not be the only hurdle. If bcftools
becomes available on i386, pysam might still not be able to build on it
because of #834856 -- that is a FTBFS on 32-bit platforms and it affects
the samtools interface. I hadn't forwarded that report to pysam upstream
because it was originally reported as a mips-specific problem. I can
probably forward that tomorrow.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#819617: [Debian-med-packaging] Bug#819617: bcftools: FTBFS: test suite fails on several architectures

[Afif Elghraoui]

Hi, Andreas,

على الجمعـة 28 تشرين الأول 2016 ‫00:18، كتب Andreas Tille:
>> Upstream's planned solution to this requires some changes to their
>> format specification (details are in the upstream bug report). I think
>> we just have to wait.
> 
> The question is how long we have to wait.  We need to get our packages
> in testing into shape until the end of this year.  This bug is open for
> quite some time which makes me wonder how long the waiting time might
> be.
>  

I don't think it will be anytime soon. The planned changes seem to have
far-reaching consequences.


>>> Alternatively we could consider to document that some tests are failing
>>> on certain architectures and let those failed tests pass.
>>
>> I don't know if this is a good idea. The tests fail because inaccurate
>> results, not crashes. If we let these through, users on these
>> architectures would unsuspectingly get wrong output.
> 
> Yes, that's perfectly true and not my prefered solution.  The question
> was actually to those who have deeper insight and if its a matter of
> NaNs which have a different representation this might be some quite
> unusual corner case (on some rarely used architectures) and thus a
> proper documentation might make sense (or not - as I said depending on
> the expert insight into this issue).

I'm sorry about that. In this case, I think you should ask on the
upstream ticket (or see if the discussion between the upstream
developers there already answers your question).

>  
>> If we /really/ want to, we could make a different package for pysam's
>> bcftools interface. Reverse-dependencies that only need the samtools
>> interface could then be untethered from this bug. I wouldn't volunteer
>> to do this, though.
> 
> Any other volunteer?  I think if the problem persists until our advent
> bug squashing party I'll ask for removal of the packages for the
> affected architectures. 
> 

We'd need a new source package, not just a new binary package for the
pysam source code. I think you can expect for this bug not to be
resolved soon, so I see that it is either the pysam source-package copy
or the removal of rdeps on i386.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#819617: [Debian-med-packaging] Bug#819617: bcftools: FTBFS: test suite fails on several architectures

[Afif Elghraoui]

Hi, Andreas,

على الخميس 27 تشرين الأول 2016 ‫23:39، كتب Andreas Tille:
> On Sun, 26 Jun 2016 16:10:02 -0700, Afif Elghraoui wrote:
>> For the record here, building with -msse2 doesn't help on i386 (build
>> log attached). According to upstream discussion, the problem has to do
>> with NaNs.
> 
> So what can we actually do with this.  Bcftools has several reverse
> (Build-)Dependencies and we need to decide whether we drop the failed
> architectures for all these.
> 

Upstream's planned solution to this requires some changes to their
format specification (details are in the upstream bug report). I think
we just have to wait.

> Alternatively we could consider to document that some tests are failing
> on certain architectures and let those failed tests pass.
> 

I don't know if this is a good idea. The tests fail because inaccurate
results, not crashes. If we let these through, users on these
architectures would unsuspectingly get wrong output.

If we /really/ want to, we could make a different package for pysam's
bcftools interface. Reverse-dependencies that only need the samtools
interface could then be untethered from this bug. I wouldn't volunteer
to do this, though.


regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#842006: RM: src:python-pbh5tools -- ROM; source package renamed to "pbh5tools"

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal

Several months ago, the python-pbh5tools package was renamed to simply
pbh5tools. The old source package (and the older versions of binary packages
it built) were not automatically removed--apparently because the renaming upload
was not part of a new upstream release. I did force upload of the upstream
tarball using the new source package name, however.

Many thanks and regards
Afif

Bug#841671: [Debian-med-packaging] Bug#841671: pbbam: Fix for building with -Wl, --as-needed

[Afif Elghraoui]

Hi, Steve,

على الجمعـة 21 تشرين الأول 2016 ‫16:28، كتب Steve Langasek:
> 
> Hi Afif,
> 
> In Ubuntu, pbbam was failing to build because when linking libpbbam.so, the
> library arguments were listed on the commandline before the objects being
> linked.  Ubuntu uses -Wl,--as-needed in its linker arguments, which causes
> libraries that aren't used to be ignored; and so libraries listed before the
> objects that use them are not linked against.
> 
> You can read more about this behavior here:
> 
>   https://wiki.ubuntu.com/ToolChain/CompilerFlags#Flags_passed_to_the_linker
> 
> I've applied a small patch in Ubuntu to fix this, with the following
> changelog explanation:
> 
>   * debian/rules: fix cmake arguments so that library arguments are in the
> right order for -Wl,--as-needed.
> 
> While Debian does not currently use -Wl,--as-needed by default and this is
> not a build issue in Debian, applying this patch will make your package more
> portable in general.  Please consider applying it.
> 

Thanks for your report and patch. I definitely have no problem applying
it. I'll upload after testing the build.

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#841396: ITP: dascrubber -- alignment-based scrubbing pipeline for DNA sequencing reads

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

* Package name: dascrubber
  Version : 0~20160601
  Upstream Author : Eugene W. Myers, Jr. 
* URL : https://github.com/thegenemyers/DASCRUBBER
* License : BSD
  Programming Lang: C
  Description : alignment-based scrubbing pipeline for DNA sequencing reads

The Dazzler Scrubbing Suite produces a set of edited reads that are guaranteed
to
 * be continuous stretches of the underlying genome (i.e. no unremoved
   adapters and not chimers)
 * have no very low quality stretches (i.e. the error rate never exceeds some
   reasonable maximum, 20% or so in the case of Pacbio data).
Its secondary goal is to do so with the minimum removal of data and splitting
of reads.


This package will be maintained by Debian Med.

Bug#837871: no need for addgroup: The group `input' already exists as a system group. Exiting. messages

[Afif Elghraoui]

Control: reassign -1 adduser
Control: affects -1 + udev


Hi, Michael and all,


On Thu, 15 Sep 2016 04:25:14 +0200 Michael Biebl <bi...@debian.org> wrote:
> Control: block -1 by 763055
> 
> Am 15.09.2016 um 01:56 schrieb 積丹尼 Dan Jacobson:
> > Package: udev
> > Version: 231-6
> > Severity: wishlist
> > 
> > Perhaps on upgrade instead of saying
> > addgroup: The group `input' already exists as a system group. 
> > Exiting.
> > say nothing, and instead just say
> > Adding group `input'.
> > if adding.
> > 
> > That way you need only make one message once,
> > instead of a message upon each upgrade.
> > 
> > And it is a message about doing something,
> > instead of a message about doing nothing.
> > 
> > No need to distract system administrators with a message about doing
> > nothing, each upgrade.
> 
> That's basically an adduser bug. We wanted to use --quiet, but this is
> broken due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763055
> 

It looks to me instead like a duplicate of
<https://bugs.debian.org/759740>. The bug you mention looks like it's
about the opposite problem--where an error occurs, but nothing is
printed because --quiet was passed.

If you agree, I would merge this ticket with #759740 and remove the
blocking relationship.


> Good luck getting adduser fixed.
> 
> 

I was going to say that this would be fixed sooner than you think, but
I'm planning to travel soon, so it could be about a month or so. :)

Thanks and regards
Afif


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#828873: openjdk-8-jre-headless: inconsistent library installation paths - workaround applied in gridengine

[Afif Elghraoui]

Control: affects -1 - src:gridengine

I've patched in special cases for arm64 and sparc64. gridengine can now
build there, so this bug doesn't affect it anymore.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#828874: hppa still FTBFS - [javac] Base64 cannot be resolved

[Afif Elghraoui]

Control: reopen -1
Control: notfixed -1 8.1.9+dfsg-2~exp1
Control: notfixed -1 8.1.9+dfsg-2
Control: retitle -1 gridengine: FTBFS on hppa

gridengine still FTBFS on hppa. There are a few errors like the following:

 [java] [javac] 81. ERROR in
/<>/gridengine-8.1.9+dfsg/source/libs/juti/java/com/sun/grid/secur
 [java] [javac] ity/login/GECATrustManagerLoginModule.java (at
line 210)
 [java] [javac] byte[] signature = Base64.decode(signatureStr);
 [java] [javac]^^
 [java] [javac] Base64 cannot be resolved


hppa (and hurd) does not have Java 8. It might need a dependency on
libcommons-codec-java to provide Base64 on this architecture.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#836553: [Debian-med-packaging] Bug#836553: Bug#836553: poretools: short gpg key used in script

[Afif Elghraoui]

Control: tag -1 + pending

Hi, Charles,

على الأحد  4 أيلول 2016 ‫06:25، كتب Charles Plessy:
> Hi Afif,
> 
> I beleive that s/E084DAB9/E298A3A825C0D65DFD57CBB651716619E084DAB9/ would 
> solve
> the problem.
> 
> By the way, this is the key of CRAN's "Ubuntu packages for R" Repository
> (https://cran.r-project.org/bin/linux/ubuntu/README.html), and I contacted the
> authors to suggest them to use a longer ID as well.  I also sent a pull 
> request
> to the Poretools author.
> 

Thanks for reporting it to the CRAN repository maintainers. As far as
poretools is concerned, all R-related packages have been dropped as
dependencies in the latest release. It seems the Dockerfile was
contributed by a third party and has not kept up. I've simply excluded
it from the tarball in the next release.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#836553: [Debian-med-packaging] Bug#836553: poretools: short gpg key used in script

[Afif Elghraoui]

Hello,

على السبت  3 أيلول 2016 ‫15:34، كتب D Haley:
> Package: poretools
> Version: 0.5.1-1
> Severity: important
> 
> Dear Maintainer,
> 
> Your package appears to contain commands which use a short gpg-key
> ID. These have recently been identified as potential security concerns,
> due to a chance that the wrong key can be imported in the case of a
> forced key-ID collision [1].
> 
> The affected file is:
>  Dockerfile [2]
> 
> Its not clear to me that the affected file is actually used in the build
> script, but it may be referenced somewhere in the package
> 

Yes, this file is not used at all during the build process or
distributed in the binary package. I believe it's just used by upstream.
I can repack the tarball and exclude this file if that will alleviate
concerns.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#833995: [Pkg-gridengine-devel] Bug#833995: gridengine: embedded tcsh copy uses deprecated BSD union wait type

[Afif Elghraoui]

Control: tag -1 + fixed-upstream

Hello,

على الخميس 11 آب 2016 ‫02:06، كتب Aurelien Jarno:
> glibc 2.24 has removed the deprecated BSD union wait type if favor of
> the POSIX 1 interface using W* macros from  (such as
> WEXITSTATUS).
> 
> glibc 2.24 is already available in experimental and will plan to upload
> it to sid in the next days/weeks. The embedded tcsh copy will fail to
> build (see bug#833965), causing in turn gridengine to fail to build from
> source. You will find attached a patch taken from upstream tcsh to fix
> the issue.
> 

Many thanks. It appears that upstream has applied this patch as well as
some similar changes elsewhere in other affected areas of the codebase [1].

Many thanks and regards
Afif

1.
https://gitlab.com/loveshack/sge/commit/538640ffe09a44a14d9f0047708f9c87d90c29ac

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#834965: virtualbox-guest-utils: should not recommend virtualbox-guest-x11

[Afif Elghraoui]

Package: virtualbox-guest-utils
Version: 5.0.24-dfsg-1
Severity: normal

Hello,

The description of virtualbox-guest-utils perfectly fits the expectation of
what someone would want on text-only VM. Unfortunately, it recommends the
virtualbox-guest-x11 package, which pulls in a ton of graphics libraries as
dependencies. Using no-install-recommends is not ideal, because the other
recommends are important. I believe virtualbox-guest-x11 should just be
downgraded to "Suggests" for this package.

Thanks and regards
Afif

Bug#834856: [Debian-med-packaging] Bug#834856: python-pysam fails to build on mips64el arch.: failed test

[Afif Elghraoui]

Control: severity -1 important
Control: tag -1 + help

Hello and thank you for the report.

على الجمعـة 19 آب 2016 ‫14:48، كتب Jonathan Jackson:
> Package: python-pysam
> Version: 0.9.1.4+ds-1
> Severity: grave
> Justification: renders package unusable
> 

While the package may be unusable on mips64el, it works well for the
vast majority of users as I understand it, so this situation deserves a
severity of 'important' rather than 'grave'.

> 
> Python-pysam packages failed to build on March 24th on a mips64el 
> architecture. Here is the tail of the failed-build log:
> 
[...]

I'd be happy to apply any patch that resolves this problem, but porting
work is beyond what I can commit to do for this package.

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#770187: Fwd: debcommit: Please merge patch to to standardize git tag version mangle

[Afif Elghraoui]

Hello,
I sent the below message to <bug#>-submitter, which apparently doesn't 
copy the maintainer, so you likely didn't see it.


Please let me know if there's anything I can do to move this along.

Many thanks and regards
Afif


 Forwarded Message 
Subject: debcommit: Please merge patch to to standardize git tag version 
mangle

Date: Sat, 16 Jul 2016 14:19:25 -0700
From: Afif Elghraoui <a...@debian.org>
To: 770187-submit...@bugs.debian.org

Control: tag -1 + patch

Hello,
I've implemented the changes proposed by Ian Jackson in this bug report.
As an affected user, I would appreciate if you would merge this patch.

The patch was created using git-format-patch, but let me know if you'd
prefer me to commit it as a topic branch directly on collab-maint.

Many thanks and regards
Afif

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

>From 1b29a12f0393fc02bb3560c8fd9cf3a475a0db5f Mon Sep 17 00:00:00 2001
From: Afif Elghraoui <a...@debian.org>
Date: Sat, 16 Jul 2016 14:09:10 -0700
Subject: [PATCH] debcommit: use standard version mangling for git tags

Closes: #770187

This patch implements the changes requested in #770187.
Please see the bug report for details about the rationale.
---
 scripts/debcommit.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/debcommit.pl b/scripts/debcommit.pl
index ce22100..2a32576 100755
--- a/scripts/debcommit.pl
+++ b/scripts/debcommit.pl
@@ -700,8 +700,8 @@ sub tag {
 	}
 }
 elsif ($prog eq 'git') {
-	$tag =~ s/^[0-9]+://; # strip epoch
-	$tag =~ tr/~/./; # mangle for git
+	$tag =~ tr/~/_/; # mangle for git
+	$tag =~ tr/:/%/;
 	if ($tag =~ /-/) {
 	# not a native package, so tag as a debian release
 	$tag = "debian/$tag";
-- 
2.1.4

Bug#776131: gridengine available in jessie-backports

[Afif Elghraoui]

Just to drop a note here; although gridengine did not make it into 
jessie proper, it has been made available to systems running jessie via 
the jessie-backports repository.


--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#832391: src:consensuscore2: python module packages come out empty on some architectures

[Afif Elghraoui]

Package: src:consensuscore2
Version: 0.12.0-1
Severity: serious

The package build is apparently unpredictable. On the various package pages
(like https://packages.debian.org/sid/python3-consensuscore2), the built
binary packages are empty. For the example below, those that are 2.6 kB only
contain package metadata, not any of the contents they're supposed to have:


Download python-consensuscore2
ArchitecturePackage SizeInstalled Size  Files
amd64   2.6 kB  11.0 kB [list of files]
i386353.6 kB1,349.0 kB  [list of files]
kfreebsd-amd64  2.6 kB  11.0 kB [list of files]
kfreebsd-i386   2.6 kB  11.0 kB [list of files] 

Download python3-consensuscore2
ArchitecturePackage SizeInstalled Size  Files
amd64   346.3 kB1,435.0 kB  [list of files]
i386353.6 kB1,349.0 kB  [list of files]
kfreebsd-amd64  2.6 kB  11.0 kB [list of files]
kfreebsd-i386   2.6 kB  11.0 kB [list of files]


None of the kfreebsd builds came out right, i386 worked for both, and am64
only worked with the python3 package. There was a similar situation in
the 0.12 version of the package currently in testing. I tested amd64
and i386 in sbuild before uploading the current version of the package
and it built fine in both cases for me, so I thought this problem would
not be coming up again. I'm not sure what's going on, so I'm filing this
bug to prevent the package from being released in this condition.

regards
Afif

Bug#832311: ITP: pbtestdata -- small Pacific Biosciences datasets for testing

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

* Package name: pbtestdata
  Version : 0.0.13
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/PacBioTestData
* License : BSD
  Programming Lang: Python
  Description : small Pacific Biosciences datasets for testing

Utility and Python API for accessing representative Pacific Bioscience
sequencing data files for testing.

This package contains common test data files that will start being
used by the packages of the smrtanalysis suite for their test suites.
It will be maintained by Debian Med.

Bug#831105: pbdagcon: FTBFS with GCC 6: cstdlib:75:25: fatal error: stdlib.h: No such file or directory

[Afif Elghraoui]

Hi, team,

On Thu, 14 Jul 2016 09:19:57 +0200 Lucas Nussbaum <lu...@debian.org> wrote:
> 
> 
> Relevant part (hopefully):
> > g++ -isystem /usr/include -I/usr/src/gtest -g -Wall -Wextra -pthread -c 
> > /usr/src/gtest/src/gtest-all.cc
> > In file included from /usr/include/c++/6/ext/string_conversions.h:41:0,
> >  from /usr/include/c++/6/bits/basic_string.h:5402,
> >  from /usr/include/c++/6/string:52,
> >  from /usr/include/c++/6/bits/locale_classes.h:40,
> >  from /usr/include/c++/6/bits/ios_base.h:41,
> >  from /usr/include/c++/6/ios:42,
> >  from /usr/include/c++/6/ostream:38,
> >  from /usr/include/gtest/gtest.h:55,
> >  from /usr/src/gtest/src/gtest-all.cc:39:
> > /usr/include/c++/6/cstdlib:75:25: fatal error: stdlib.h: No such file or 
> > directory
> >  #include_next 
> >  ^
> > compilation terminated.
> > make[2]: *** [gtest-all.o] Error 1
> 

Just a quick note about this. I believe this problem can be resolved by
replacing all "-isystem" flags with "-I" in the build system. I haven't
implemented this change here yet because I was planning to update the
packages to a new upstream revision (upstream doesn't label releases...).

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#826042: Spyder crashes on start

[Afif Elghraoui]

Hi, Jitse,

[Cc'ing Picca, who is listed as an uploader of the package and made the
last update in Unstable]

على الخميس 14 تـمـوز 2016 ‫13:05، كتب Jitse Niesen:
> I have recently become a developer with Spyder and I would dearly like 
> to have Spyder back into Debian. Is there anything I can do to help?
> 

If it's the case as it appears to be that the usual caretakers of this
package don't have time for it anymore, you may want to join Debian
Science and take over maintaining the package here. I could help you get
started with Debian packaging if you're interested.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#831523: RM: python-kineticstools [armel mipsel] -- ROM; not installable

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


This package is not installable on the named architectures because
of the absence of python-pysam there.

Many thanks and regards
Afif

Bug#831522: RM: pbh5tools [armel mipsel] -- ROM; not installable

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


This package is not installable on the named architectures because
of the absence of python-pysam there.

Thanks and regards
Afif

Bug#831520: RM: pbbarcode [armel mipsel i386 kfreebsd-i386] -- ROM; not installable

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


This package is not installable on the named architectures because
of its eventual dependency python-pysam not being available there.

Thanks and regards
Afif

Bug#831516: RM: pbbam [i386 armel mipsel] -- ROM; Antiquated and prevents testing migration

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


The latest upload of the pbbam package has major changes, a new binary package,
and also runs a test suite. This test suite fails on 32-bit platforms,
where the original (very old version) used to be able to build.
The presence of the outdated binaries on the named architectures prevents
testing migration while upstream appears not interested in supporting them.

You might also prefer to remove the outdated binaries on the non-release
architectures for purposes of cruft removal.

Thanks and regards
Afif

Bug#829741: pbbam: severity is important

[Afif Elghraoui]

Control: severity -1 important

I have reported this upstream, but have not gotten a response. It is not
clear that they care for 32-bit platforms. In any case, I do not think
that this bug represents a regression, because the first version
uploaded was a minimal early release. The latest uploaded version adds
much more functionality and runs a test suite that wasn't run before.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#828199: RM: python-pysam [armel mipsel] -- ROM; FTBFS (test suite failures)

[Afif Elghraoui]

Control: tag -1 - moreinfo

Hi, Scott,

I have to say first that I did not receive your email (and manually
followed up on the bug log to notice that you had answered me) because
you didn't use <bug#>-submit...@bugs.debian.org or otherwise Cc me. The
BTS unfortunately doesn't auto-subscribe submitters.


On Wed, 29 Jun 2016 00:24:43 -0400 Scott Kitterman <sc...@kitterman.com>
wrote:
> 
> There are a number of rdepends that need to be dealt with:
> 
> Checking reverse dependencies...
> # Broken Depends:
> ariba: ariba
> circlator: circlator
> pbalign: python-pbalign
> pbsuite: pbhoney
>  python-pbsuite-utils
> python-pbcore: python-pbcore
> 

All of these packages are arch:all. The arch-dependent rdeps have all
been taken care of already.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#829645: src:gtest: Cannot build against libgtest-dev with std=c++11

[Afif Elghraoui]

Package: src:gtest
Version: 1.7.0-4
Severity: important

Hello,

I'm trying to enable tests for the pbbam package, but there is a compilation 
error that is triggered by simply including gtest.h:


tests/CMakeFiles/test_pbbam.dir/build.make:65: recipe for target 
'tests/CMakeFiles/test_pbbam.dir/src/test_Accuracy.cpp.o' failed
make[3]: *** [tests/CMakeFiles/test_pbbam.dir/src/test_Accuracy.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from /usr/include/gtest/internal/gtest-port.h:213:0,
 from /usr/include/gtest/internal/gtest-internal.h:40,
 from /usr/include/gtest/gtest.h:58,
 from /<>/tests/src/test_AlignmentPrinter.cpp:43:
/usr/include/c++/5/sstream:300:7: error: ‘struct 
std::__cxx11::basic_stringbuf<_CharT, _Traits, _Alloc>::__xfer_bufptrs’ 
redeclared with different access
   struct __xfer_bufptrs
   ^
In file included from /usr/include/gtest/internal/gtest-port.h:213:0,
 from /usr/include/gtest/internal/gtest-internal.h:40,
 from /usr/include/gtest/gtest.h:58,
 from /<>/tests/src/test_BamFile.cpp:43:
/usr/include/c++/5/sstream:300:7: error: ‘struct 
std::__cxx11::basic_stringbuf<_CharT, _Traits, _Alloc>::__xfer_bufptrs’ 
redeclared with different access
   struct __xfer_bufptrs
   ^
tests/CMakeFiles/test_pbbam.dir/build.make:89: recipe for target 
'tests/CMakeFiles/test_pbbam.dir/src/test_AlignmentPrinter.cpp.o' failed



Line 43 of my file /<>/tests/src/test_AlignmentPrinter.cpp has:

#include 

The error looks like one of the GCC transition issues, and the last formal
gtest release is several years old despite the code base being actively
developed. I think it would be good to update the package to a recent git
snapshot since it seems upstream cannot be convinced to make a new release [1].

Many thanks and regards
Afif

1. https://github.com/google/googletest/issues/746

Bug#829622: [Debian-med-packaging] Bug#829622: consensuscore2: FTBFS on hurd-i386: 'dict' object has no attribute 'iteritems'

[Afif Elghraoui]

على الإثنين  4 تـمـوز 2016 ‫12:08، كتب Aaron M. Ucko:
> Source: consensuscore2
> Version: 0.12.0-1
> Severity: important
> Justification: fails to build from source
> 
> The hurd-i386 build of consensuscore2 failed when trying to install
> the Python 3 module:
> 
[...]
> 
> The dict.iteritems method is only available in Python 2.x, but it
> looks like the (Linux) i386 build was unaffected because it didn't
> invoke setup.py here at all:
> 
>  dh_auto_install -a -O--buildsystem=pybuild
>   I: pybuild base:184: dh_auto_install --buildsystem=cmake 
> --builddirectory="/«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build" 
> --destdir="/«PKGBUILDDIR»/debian/python-consensuscore2" -- 
>   I: pybuild base:184: dh_auto_install --buildsystem=cmake 
> --builddirectory="/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build" 
> --destdir="/«PKGBUILDDIR»/debian/python3-consensuscore2" -- 
>  dh_install -a -O--buildsystem=pybuild
> 
> I'm not sure offhand why not.  Could you please take a look?
> 

It looks like the linux i386 python module packages come out empty.
Thanks for pointing this out. I'll have a look.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#829395: [Debian-med-packaging] Bug#829395: python-cobra: FTBFS on hurd-i386: This platform lacks a functioning sem_open implementation

[Afif Elghraoui]

Control: reassign -1 ftp.debian.org
Control: severity -1 normal
Control: retitle -1 RM: python-cobra [hurd-i386] -- RoM; FTBFS; platform
lacks a functioning sem_open implementation

This doesn't look trivially fixable, so requesting decrufting as advised.

regards
Afif


على السبت  2 تـمـوز 2016 ‫16:07، كتب Andreas Beckmann:
> Source: python-cobra
> Version: 0.4.1-2
> Severity: important
>
> Hi,
>
> python-cobra FTBFS on hurd-i386, but the previous version built there:
>
>
https://buildd.debian.org/status/fetch.php?pkg=python-cobra=hurd-i386=0.4.1-2=1464980277
>
> test_double_gene_deletion
(cobra.test.flux_analysis.TestCobraFluxAnalysis) ... ERROR
> Exception AttributeError: "'CobraDeletionPool' object has no attribute
'processes'" in > ignored
>
> ==
> ERROR: test_double_gene_deletion
(cobra.test.flux_analysis.TestCobraFluxAnalysis)
> --
> Traceback (most recent call last):
>   File "/«PKGBUILDDIR»/cobra/test/flux_analysis.py", line 170, in
test_double_gene_deletion
> solution = double_gene_deletion(cobra_model, gene_list1=genes)
>   File "/«PKGBUILDDIR»/cobra/flux_analysis/double_deletion.py", line
283, in double_gene_deletion
> gene_id_to_result, **kwargs)
>   File "/«PKGBUILDDIR»/cobra/flux_analysis/double_deletion.py", line
403, in _double_gene_deletion_fba
> solver=solver, **kwargs) as pool:
>   File "/«PKGBUILDDIR»/cobra/flux_analysis/deletion_worker.py", line
66, in __init__
> self.job_queue = Queue()  # format is (indexes, job_label)
>   File "/usr/lib/python2.7/multiprocessing/__init__.py", line 217, in
Queue
> from multiprocessing.queues import Queue
>   File "/usr/lib/python2.7/multiprocessing/queues.py", line 48, in

> from .synchronize import Lock, BoundedSemaphore, Semaphore, Condition
>   File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 59,
in 
> " function, see issue 3770.")
> ImportError: This platform lacks a functioning sem_open
implementation, therefore, the required synchronization primitives
needed will not function, see issue 3770.
>
> --
> Ran 129 tests in 6.040s
>
> FAILED (errors=1, skipped=11)
>
>
> If this is not trivially fixable, please request decrufting of the
> outdated binary packages:
>
> Control: reassign -1 ftp.debian.org
> Control: severity -1 normal
> Control: retitle -1 RM: python-cobra [hurd-i386] -- RoM; FTBFS;
platform lacks a functioning sem_open implementation
>


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#829515: [Debian-med-packaging] Bug#829515: htseq: B-D python-pysam not available on all architectures where htseq previously built

[Afif Elghraoui]

Hello,

على الأحد  3 تـمـوز 2016 ‫15:39، كتب Andreas Beckmann:
> Package: htseq
> Version: 0.6.1p1-4
> Severity: serious
> Justification: fails to build from source
> 

I'm not sure about this severity, because there's only one case of
FTBFS. the rest are BD-uninstallable.

The build failure on armel [1] is because of one test failure:

testing on architecture arm
python2.7 test/test.py
Doctest of tss.rst:
**
File "../doc/tss.rst", line 114, in tss.rst
Failed example:
wincvg
Expected:
array([0, 0, 0, ..., 0, 0, 0], dtype=int32)
Got:
array([0, 0, 0, ..., 0, 0, 0])
**

> htseq 0.6 added a Build-Depends: python-pysam (for testing),
> but that is only available on a few architectures.
> 
> Either restrict this to the architectures where it is available or
> request decrufting of the outdated binary packages on the architectures
> where it is missing/failing.
> 

Maybe removal on just armhf, mips, powerpc, and s390x if the armel build
can be fixed. Those are what are holding up testing migration [2].

regards
Afif

1.
https://buildd.debian.org/status/fetch.php?pkg=htseq=armel=0.6.1p1-4=1449681506
2. https://release.debian.org/migration/testing.pl?package=htseq

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#829519: RM: kineticstools [i386 kfreebsd-i386 hurd-i386] -- ROM; not installable

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


This package indirectly depends on python-pysam, which is no longer available
for any-i386. Testing migration of the new kineticstools upload is currently
blocked by the lack of an i386 build.

Many thanks and regards
Afif

Bug#829510: ITP: consensuscore2 -- generate consensus sequences for PacBio sequencing data

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

* Package name: consensuscore2
  Version : 0.12.0
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/ConsensusCore2
* License : BSD
  Programming Lang: C++, Python
  Description : generate consensus sequences for PacBio sequencing data

ConsensusCore2 embodies core C++ routines underlying the Arrow HMM
algorithm for PacBio multi-sequence consensus.  Arrow is the successor
to the Quiver model---a CRF model that was embodied in the
ConsensusCore C++ library. Compared to Quiver, the Arrow model is more
statistically principled and easier and more robust to train.


This package will become a Depends or Recommends of the pbgenomicconsensus
package. It will be maintained by the Debian Med team.

Bug#829506: ITP: flask-multistatic -- A simple flask plugin for overriding static files

[Afif Elghraoui]

على الأحد  3 تـمـوز 2016 ‫15:15، كتب Sergio Durigan Junior:
[...]
> 
> This package is a dependency necessary for pagure.
> 

Many thanks for working towards a pagure package! It looks like a very
nice thing to have in Debian.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#829393: RM: pbh5tools [i386 kfreebsd-i386] -- ROM; not installable

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


pbh5tools depends on pysam, which is not built for {kfreebsd-,}i386 anymore
and has already been removed from those architectures.

Many thanks and regards
Afif

Bug#828837: [Debian-med-packaging] Bug#828837: python-pbconsensuscore: please also build a C++ library

[Afif Elghraoui]

Control: tag -1 + confirmed

Hi, Sascha,

على الثلاثاء 28 حزيران 2016 ‫03:30، كتب Sascha Steinbiss:
> Source: python-pbconsensuscore
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I'm currently working to eliminate embedded code copies in another package
> (spades) and ConsensusCore is used there as a C++ library.
> I see that while this source package also contains the C++ code, it only
> builds Python modules.

Yes, it builds the C++ code as binary python extensions.

> It would be nice to also build a binary library
> package, given that make/Cpp.mk alreasy seems to include a target for such
> a library.
> 

I think this is a great idea and will add it to my to-do list. There's
also a ConsensusCore2 in development that I plan to package at some
point, but I'm not sure if this is relevant for spades. ConsensusCore2
should be co-installable with ConsensusCore anyway.

Thanks and regards
Afif


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#829040: pandoc-citeproc: Should declare relationship with ca-certificates

[Afif Elghraoui]

Package: pandoc-citeproc
Version: 0.9-1
Severity: normal

While creating a Stretch chroot to work around #765091 in jessie,
I was still missing a dependency when trying to run pandoc-citeproc (via 
pandoc):

pandoc paper.tex -s --bibliography=references.bib --csl=style.csl -o paper.html
pandoc-citeproc: TlsExceptionHostPort (HandshakeFailed (Error_Protocol 
("certificate has unknown CA",True,UnknownCa))) "www.zotero.org" 80
pandoc: Error running filter pandoc-citeproc
Filter returned error status 1

This error went away after I installed ca-certificates, so I think this should 
be declared by pandoc-citeproc.

Many thanks and regards
Afif

Bug#826113: [Pkg-gridengine-devel] Bug#826113: bugfix

[Afif Elghraoui]

Control: tag -1 + pending

Hello,

على الأحد 26 حزيران 2016 ‫19:45، كتب Carl Pupa:
> 
> When I applied your patch, did debuild, and then ran piuparts -d stretch 
> on the gridengine-common*.deb, I got the following, indicating that it 
> was still looking for the gridengine.default file:

Yeah, I noticed that while running piuparts earlier today. Fortunately,
I fixed it before upload.

> 
>update-alternatives: using /bin/tcsh to provide /bin/csh (csh) in 
> auto mode
>Setting up gridengine-common (8.1.8+dfsg-6) ...
>ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be 
> preloaded (cannot open shared object file): ignored.
>sed: can't read /usr/share/gridengine-common/gridengine.default: No 
> such file or directory

I needed to have /usr/share/gridengine/..., instead of
/usr/share/gridengine-common/... here

[...]

Anyway, thanks for taking a look! I uploaded the package earlier today
with the corrected patch. The latest changes should already be in git,
but the package itself needs ftpmaster approval before it can enter the
archive because I added a new binary package (gridengine-dev).


Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#819617: bcftools i386 - update on compiling with -msse2

[Afif Elghraoui]

For the record here, building with -msse2 doesn't help on i386 (build
log attached). According to upstream discussion, the problem has to do
with NaNs.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


bcftools_1.3.1-2_i386.build.gz
Description: application/gzip

Bug#828202: RM: fitgcp [armel mipsel] -- ROM; unsatisfiable dependency

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal
Control: block 828199 by -1

This package depends on python-pysam, which does not successfully build on the 
architectures in question.
It will cease to be installable there once python-pysam is removed, so this one 
should be removed first.

Thanks and regards
Afif

Bug#828200: RM: sga [armhf mips powerpc s390x armel mipsel i386] -- ROM; unsatisfiable dependencies

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


This package has been blocked from testing migration for a long time.
The testing excuses page mentions armhf, mips, powerpc, and s390x [1].
However, python-pysam is additionally not available for i386, (and
(recently) armel and mipsel.

Many thanks and regards
Afif

1. https://release.debian.org/migration/testing.pl?package=sga

P.S. Is there a way to avoid filing this removal for each new upload without 
copying the Depends list into Build-Depends?

Bug#828199: RM: python-pysam [armel mipsel] -- ROM; FTBFS (test suite failures)

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


Up until the 0.9.1 upstream release, the test suite had spurious failures, so 
they were being ignored.
Now that the exit status is not ignored, we notice real test failures on armel 
and mipsel, so even though the 0.9.0 package successfully compiled there 
before, the package is probably still failing those tests and should be removed 
from those architectures.

Thanks and regards
Afif

Bug#826113: Found in all prior releases

[Afif Elghraoui]

Control: found -1 6.2~beta-1

Looks like this problem was introduced in commit
50d1580b5b91f65e9a33a205a90a7c6925d45e8d (2008), which was part of the
package's initial release. I'm not sure if this was a policy violation
back then, though.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#826113: [Pkg-gridengine-devel] Bug#826113: bugfix

[Afif Elghraoui]

على السبت 25 حزيران 2016 ‫16:35، كتب Carl Pupa:
> In that case I agree it doesn't really matter whether gridengine.default 
> is in examples or not.  I've attached a patch that simply change the 
> postinst script so that it takes the copy from 
> /usr/share/gridengine-common/ instead of /usr/share/doc/gridengine-common/.

This is close. Attached is what I had in mind as a complete solution. It
installs gridengine.default into /usr/share/gridengine-common/, does not
install it into /usr/share/doc/gridengine-common/examples/, and adjusts
the postinst script (like your patch did).

The debian/*examples and debian/*install files are used by
dh_installexamples(1) and dh_install(1), respectively, during the
package build. debhelper(7) has a list of similar commands.

Does this look good to you? I haven't tested it, but it looks ok to me.

Many thanks and regards
Afif


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
diff --git a/debian/gridengine-common.examples b/debian/gridengine-common.examples
index 26bbb9f..b076ca9 100644
--- a/debian/gridengine-common.examples
+++ b/debian/gridengine-common.examples
@@ -1,4 +1,3 @@
 debian/tmp/usr/examples/jobs/*
-debian/gridengine.default
 debian/tmp/usr/pvm
 debian/tmp/usr/mpi
diff --git a/debian/gridengine-common.install b/debian/gridengine-common.install
index 8ce7ddf..e30ab25 100644
--- a/debian/gridengine-common.install
+++ b/debian/gridengine-common.install
@@ -3,6 +3,7 @@ debian/tmp/default-configuration	usr/share/gridengine
 debian/tmp/default-bootstrap	usr/share/gridengine
 debian/scripts usr/share/gridengine
 debian/gridengine-wrapper   /usr/share/gridengine
+debian/gridengine.default	/usr/share/gridengine
 debian/tmp/usr/util		usr/share/gridengine
 debian/tmp/usr/mpi		usr/share/gridengine
 debian/tmp/usr/pvm		usr/share/gridengine
diff --git a/debian/gridengine-common.postinst b/debian/gridengine-common.postinst
index 8b986f9..ea3d071 100755
--- a/debian/gridengine-common.postinst
+++ b/debian/gridengine-common.postinst
@@ -54,7 +54,7 @@ case "$1" in
   TMPFILE=$(mktemp)
   chown root:root ${TMPFILE}
   chmod 644 ${TMPFILE}
-  sed "s@^SGE_CELL=.*@SGE_CELL=${SGE_CELL}@" /usr/share/doc/gridengine-common/examples/gridengine.default >> ${TMPFILE}
+  sed "s@^SGE_CELL=.*@SGE_CELL=${SGE_CELL}@" /usr/share/gridengine-common/gridengine.default >> ${TMPFILE}
   ucf --debconf-ok ${TMPFILE} /etc/default/gridengine
   rm -f ${TMPFILE}
 else

Bug#827638: ITP: sniffles -- structural variation caller using third-generation sequencing

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Afif Elghraoui <a...@debian.org>

* Package name: sniffles
  Version : 0.0.1
  Upstream Author : Fritz Sedlazeck <fritz.sedlaz...@gmail.com>
* URL : https://github.com/fritzsedlazeck/Sniffles
* License : MIT
  Programming Lang: C++
  Description : structural variation caller using third-generation 
sequencing

 Sniffles is a structural variation caller using third-generation sequencing
 platforms such as those from Pacific Biosciences or Oxford Nanopore.
 It detects all types of SVs using evidence from split-read alignments,
 high-mismatch regions, and coverage analysis.


Packaging will be maintained by the Debian Med team.

Bug#827076: src:gridengine: FTBFS with openssl 1.1.0

[Afif Elghraoui]

Package: src:gridengine
Version: 8.1.8+dfsg-6
Severity: important

As posted by Kurt Roeckx to debian-devel [1]:

~~~
The release of OpenSSL 1.1.0 is getting nearer.  Some packages
will no longer build with the new version without changes.  Most
of those changes should be trivial, like you can't allocate some
structures on the stack anymore and need to use the correct _new()
and _free() function.

It can also mean that you can't directly access some members of
those structures anymore and need to use a function instead.

There is an upstream wiki page for this at:
https://wiki.openssl.org/index.php/1.1_API_Changes

If things aren't clear, you have questions, are there are missing
access functions please contact us.

I've uploaded packages to experimental, so you can use those to
test things.

We did a rebuild of all packages build-depending on libssl-dev.
You can see the result of that here:
https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/
~~~

The build log for gridengine is at 


The severity is set to important until the transition becomes imminent, after 
which it should become release-critical.

1. https://lists.debian.org/debian-devel/2016/06/msg00205.html