Bug#1011129: gridengine: FTBFS with OpenJDK 17 due to JDK detection error

[Afif Elghraoui]

On 5/20/22 09:12, Dave Love wrote:

I thought it failed with earlier openjdk than that because of jgdi being
removed,


It failed with earlier openjdk *because* of jgdi [1]. I sent you an 
issue upstream, but my workaround back then was to just skip building jgdi.




but I think it needs to use

   aimk -no-java ...

I don't know what JDK versions it needs to check for, but it's probably
not worth any effort to get that right.  I'm not sure whether you can
still build jdrmaa, at least.

I look at it immediately, but can probably can in a bit as I need to
resurrect rpm builds anyway.


Does this mean SGE is being revived?

thanks and regards
Afif

1. https://bugs.debian.org/875404

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

Bug#995171: need newer release

[Afif Elghraoui]

Hi, Andreas!

On 1/24/22 07:24, Andreas Tille wrote:

I might have a look once I get permissions to push directly.


Access granted. I don't get email notifications when someone makes an 
access request, so I rely on someone emailing the list saying "hey, I 
want to join"


thanks and regards
Afif

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

Bug#982407: mark libfabric1 Multi-Arch: same

[Afif Elghraoui]

On 12/14/21 7:48 AM, tony mancill wrote:
> On Tue, Feb 09, 2021 at 09:25:09PM +0100, Helmut Grohne wrote:
>> Package: libfabric1
>> Version: 1.11.0-2
>> Tags: patch
>> User: debian-cr...@lists.debian.org
>> Usertags: cross-satisfiability
>>
>> The affected packages cannot satisfy their cross Build-Depends, because
>> they request coinstalling libfabric1, but libfabric1 is not marked
>> Multi-Arch: same. It can be thus marked, because it does not have any
>> conflicting files. Please consider applying the attached patch.
> 
> Hi Debian HPC,
> 
> Any concerns with an NMU or team upload of this change?  I don't work in
> HPC and came across this bug via Debian Med (it affects the abyss
> package), so when I say "team" upload, I merely keeping the packaging
> repo updated.  I have requested team access via Salsa.  
> 

Hello,

I'm not involved with the package, but I've granted you access and any
help is welcome as far as I'm concerned.

thanks and regards
Afif

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

Bug#931345: nvchecker: autopkgtest regression in June 2019

[Afif Elghraoui]

Hello,

On 11/12/20 2:11 AM, Paul Gevers wrote:
> severity 931345 serious
> user debian...@lists.debian.org
> usertag 931345 timeout
> thanks
> 
> please upload a fixed package.
> 
> The test if timing out nowadays too, so I'll block it from being tested
> to avoid stress on our infrastructure until this bug is fixed.
> 

This bug has been fixed for about a week now but nvchecker still appears
to be blocked from debci. Does that need to be manually changed? I
expected it to be removed automatically once the bug was closed.

thanks and regards
Afif

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

Bug#953977: gridengine-drmaa1.0: Please install libdrmaa.so.1.0 into standard library dir

[Afif Elghraoui]

On 9/26/21 1:37 PM, Andreas Tille wrote:
> Hi Afif,
> 
> On Sun, Sep 26, 2021 at 01:20:34PM -0700, Afif Elghraoui wrote:
>>> My guess is that also other packages than python3-drmaa will profit from
>>> this.
>>
>> The thing is that gridengine is not the only implementation of drmaa,
>> though it seems to be the only one in current Debian releases. If we
>> wanted to do this right, I think we'd need to get a virtual package for
>> libdrmaa that gridengine and, for example, slurm could both provide.
> 
> would you volunteer to work on an accoring solution?
> 

I don't think so...at least not in the near term.

regards
Afif

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

Bug#953977: gridengine-drmaa1.0: Please install libdrmaa.so.1.0 into standard library dir

[Afif Elghraoui]

On 3/15/20 2:44 AM, Andreas Tille wrote:
> as you can read in bug #953832 I need a patch[1] for python-drmaa to find
> libdrmaa.so.1.0.  As Sergio pointed out in his comment[2] this is due an
> unusual location of the library.  It would be great if you would consider
> installing it rather to
> 
> /usr/lib/${DEB_HOST_MULTIARCH}/
> 
> instead of
> 
> /usr/lib/gridengine-drmaa/lib/
> 
> My guess is that also other packages than python3-drmaa will profit from
> this.

The thing is that gridengine is not the only implementation of drmaa,
though it seems to be the only one in current Debian releases. If we
wanted to do this right, I think we'd need to get a virtual package for
libdrmaa that gridengine and, for example, slurm could both provide.

thanks and regards
Afif

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

Bug#937738: python-et-xmlfile: diff for NMU version 1.0.1-2.1

[Afif Elghraoui]

On ٨‏/٦‏/١٤٤١ هـ ١٢:١٥ م, Sandro Tosi wrote:
> Control: tags 937738 + patch
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for python-et-xmlfile (versioned as 1.0.1-2.1). The diff
> is attached to this message.
> 
> Consider maintaining this package with the DPMT
> 

I'd have been happy to, but at the time, DPMT was using git-dpm and it
didn't seem worth learning to use an unmaintained tool just to package a
couple of python modules.

Thanks and regards
Afif

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

Bug#947154: ITS: yubioath-desktop due to lack of activity

[Afif Elghraoui]

Hi, Taowa

On Sat, 21 Dec 2019 19:54:11 -0500 Taowa Munene-Tardif 
wrote:
> Hello,
> 
> As per [0] and the removal from unstable, I intend to salvage the
> package yubioath-desktop. Should anyone object, please let me know. 
> 
> [0] 
> https://github.com/Yubico/yubioath-desktop/issues/328#issuecomment-513132914
> 

Since the package is team-maintained, I think it'd be easier for you to
just join the team and continue maintaining the package as part of it.
In this case, I don't think an ITS is necessary and you could just do a
team upload.

thanks and regards
Afif

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

Bug#931345: nvchecker: autopkgtest regression in June 2019

[Afif Elghraoui]

Control: forwarded -1 https://github.com/lilydjwg/nvchecker/issues/109


On July 2, 2019 2:50:00 PM EDT, Paul Gevers  wrote:
>Source: nvchecker
>Version: 1.3-2
>Severity: important
>X-Debbugs-CC: debian...@lists.debian.org
>User: debian...@lists.debian.org
>Usertags: regression
>
>Dear maintainers,
>
>Somewhere between 2019-05-28 and 2019-06-28, your package started to
>fail in buster for version 1.3.2, and somewhere between 2019-06-10 and
>2019-06-15 is started failing in unstable for version 1.4.3-1.
>
>I copied some of the output at the bottom of this report.
>
>Unfortunately, the regression isn't caught by the migration software,
>so
>this is either caused by an indirect dependency of your package (maybe
>hints can be found here [1]), or by an external factor. Please
>investigate and fix your autopkgtest.
>

Already known and forwarded.

thanks and regards
Afif

>
>[1]
>https://ci.debian.net/data/packages/unstable/amd64/n/nvchecker/2492039.log
>
>https://ci.debian.net/data/autopkgtest/unstable/amd64/n/nvchecker/2492039/log.gz
>

Bug#929011: unblock: singularity-container/3.1.1+ds-1

[Afif Elghraoui]

On June 28, 2019 5:00:00 AM EDT, Ivo De Decker  wrote:
>Hi,
>
>On Thu, Jun 27, 2019 at 09:30:09AM -0400, Afif Elghraoui wrote:
>> On June 27, 2019 9:06:41 AM EDT, Afif Elghraoui 
>wrote:
>> >
>> >
>> >On June 27, 2019 5:47:28 AM EDT, Ivo De Decker 
>> >wrote:
>> >>Hi,
>> >>> 
>> >>> So I think the two options we have is (in order of preference):
>1.
>> >>> unblock singularity-container and let the 3.1 based version in to
>> >>> buster, or 2. remove singularity-container from buster.
>> >>
>> >>It's really too late for option 1. Sorry.
>> >>
>> >>I added a removal hint.
>> >>
>> >
>> >This request was not just filed recently. I don't understand why I'm
>> >being penalized for this being late--the version requested for
>> >unblocking as been in unstable for 43 days with no new bugs. And
>it's
>> >also a leaf package.
>> >
>> >Please reconsider.
>> >
>> 
>> I at least want to know what I could have done because, from my
>perspective,
>> I did everything in my power to do this as quickly as possible. At
>the time
>> I made the request, the buster release date had not yet even been
>set.
>
>Please look at the freeze policy:
>
>https://release.debian.org/buster/freeze_policy.html

I have seen it. I hoped we would be trying to make the best possible release 
rather than just following the freeze policy for its own sake. My understanding 
of its strictness is to keep packages with reverse-dependencies from breaking 
them with large changes.

This was a very low/no-risk request because it is a leaf package. firefox-esr 
updates to new versions all the time for security support and actually does 
break reverse-dependency packages in Stable much of the time as a result.

>
>The upload of 3.1.1+ds-1 was done on 2019-05-15, the full freeze
>started on
>2019-03-12. 
>
>During the full freeze, we only accept targeted fixes. Your upload
>didn't come
>close to that, as you admitted yourself in your original mail to the
>unblock
>request. The chances of such a request being granted were extremely
>small,
>even at the point the request was made.
>
>The unblock won't be granted. Sorry.
>


Removal of the existing version in buster, on the other hand, I thought was too 
extreme. I would have tried to support 3.0.3 in buster if any CVEs in it came 
up  and, if that proved too difficult, asked for the exemption to bump to this 
3.1 lts version again at that point.

regards
Afif

Bug#929011: unblock: singularity-container/3.1.1+ds-1

[Afif Elghraoui]

Control: reopen -1

On June 27, 2019 9:06:41 AM EDT, Afif Elghraoui  wrote:
>
>
>On June 27, 2019 5:47:28 AM EDT, Ivo De Decker 
>wrote:
>>Hi,
>>> 
>>> So I think the two options we have is (in order of preference): 1.
>>> unblock singularity-container and let the 3.1 based version in to
>>> buster, or 2. remove singularity-container from buster.
>>
>>It's really too late for option 1. Sorry.
>>
>>I added a removal hint.
>>
>
>This request was not just filed recently. I don't understand why I'm
>being penalized for this being late--the version requested for
>unblocking as been in unstable for 43 days with no new bugs. And it's
>also a leaf package.
>
>Please reconsider.
>

I at least want to know what I could have done because, from my perspective, I 
did everything in my power to do this as quickly as possible. At the time I 
made the request, the buster release date had not yet even been set. I followed 
up on the docker bugs and offered to help and was told by the maintainer it was 
under control.

The singularity community was really looking forward to having the package in 
Debian Stable this time around.

regards
Afif

Bug#929011: unblock: singularity-container/3.1.1+ds-1

[Afif Elghraoui]

Control: tag -1 - moreinfo

On June 25, 2019 4:16:17 PM EDT, Salvatore Bonaccorso  wrote:
>Hi Paul, hi Afif,
>
[...]
>> 
>> Your proposed changes very much do not align with the freeze policy,
>so
>> you're asking for an exception for a new upstream release. This
>package
>> is currently listed to be auto-removed due to docker.io, so I am not
>> going to review it now. docker.io is a major concern for the
>> security-team so that needs to be resolved first. If that gets
>resolved
>> in a timely manner, i.e. before it is auto-removed, please ping this
>bug
>> (e.g. by removing the moreinfo bug).
>
>I do agree that the changes are not really reviewable given the size
>of the diff. But with Afifs argument and now the package not beeing
>marked as autoremoved: if we want to support singularity-container
>security wise in buster we would need to bite into the apple and
>accept this late new version bump for buster as the 3.1 version.
>
>So I think the two options we have is (in order of preference): 1.
>unblock singularity-container and let the 3.1 based version in to
>buster, or 2. remove singularity-container from buster.
>
>Cc'in team@s.d.o for further comments.
>

Thanks, Salvatore. I'm removing the moreinfo tag as Paul said to do since the 
autoremoval warning has been lifted.

regards
Afif

Bug#929662: docker.io: CVE-2018-15664 - upstream backport of patch for 18.09

[Afif Elghraoui]

Hello,

Is any help needed on this? Upstream has a backport of the patch for the
18.09 series (same as Unstable):

  https://github.com/docker/engine/pull/253

Hopefully it won't be too much work to incorporate it.

thanks and regards
Afif

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

Bug#903635: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Afif Elghraoui]

Hello,

On Fri, 24 May 2019 10:33:34 +0100 Jonathan Dowland  wrote:
> Hi Arnaud - sorry I missed your messages until now.
> 
> On Fri, May 10, 2019 at 09:03:41AM +0700, Arnaud Rebillout wrote:
> >As I mentioned above, there's a discussion with a work in progress to
> >fix that upstream: https://github.com/docker/libnetwork/pull/2339
> >
> >I don't think it will be ready in time for buster though. So I see two
> >solutions going forward:
> >
> >- 1 Jonathan lower the severity of the bug so that it's not RC.
> 
> I'd rather not do that, because I think RC is the right classification;
> *but* I don't feel necessarily (given the circumstances) that docker.io
> should be removed from Buster, so can I instead suggest we request that
> this bug is ignored for Buster?

I don't understand... I thought the whole point of making a bug
release-critical is to keep the bug out of the release (either by having
it fixed or removing the package).

> I think we need to ask the release team
> to do that (and tag accordingly) but I'll double-check the procedure.
> 

It seems to me like the severity of this bug should just be lowered, but
if you want to pursue a buster-ignore tag, someone please contact the
release team and make it happen. https://www.debian.org/Bugs/Developer
says explicit authorization is needed from the release managers, but I'd
worry that an email to debian-rele...@lists.debian.org might get lost
and it'd be weird to file a bug on release.debian.org asking to apply a
tag to another bug.

Again, I think it makes more sense to just lower the severity if you
don't think it should affect the release.

regards
Afif

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

Bug#926556: unblock: yubikey-personalization/1.19.3-3 - now accepted to Unstable

[Afif Elghraoui]

Control: tag -1 - moreinfo

Hello,

The package just passed NEW today, so should be ready to go.

thanks and regards
Afif

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

Bug#756954: subscription by uploaders

[Afif Elghraoui]

Hello,

على ٧‏/٧‏/١٤٤٠ هـ ‫٥:٢٢ م، كتب Raphael Hertzog:
> Hello Afif,
> 
> sorry for the delay.

I read your reply before and put it aside for later, but reading it
again now, I have a comment--

> 
> On Sun, 03 Feb 2019, Afif Elghraoui wrote:
>> The way I was hoping this could work is that Uploaders are automatically
>> subscribed. I don't know of any reason why an Uploader should not be
>> following their packages. I think it would also motivate people who
>> really don't co-maintain a package to get themelves removed from the
>> Uploaders list, thereby correcting the package metadata.
> 
> Uploaders should be following their packages but they might already be
> following their packages in some other way: through a (tracker-)team
> subscription. Or through a mailing list that is referenced in the
> Maintainer field.
> 

Yes, but this would be addressed by the mechanism you described in the
requirement below [1]

> So maintainers should be able to opt-out from this automatic subscription
> or at least blacklist some packages (so that a manual unsubscription is
> not followed by an automatic subscription because of the Uploaders field).
> 

One of the main points of this feature as I see it is that it helps to
keep the Uploaders field accurate. If co-maintainers want to completely
unsubscribe, why shouldn't they achieve this by just removing themselves
from Uploaders altogether?


>> I think this would also be simpler to implement than subscription
>> keywords in d/control (as mentioned in the OP). If it's still too far
>> out of you way, I'd be willing to implement a patch, but would
>> appreciate a tip about where to look in the code-base. I looked around
>> it and couldn't find a good starting point in the file hierarchy.
> 
> I believe this feature is important and it would be nice to have it
> working in the not too distant future but I'm unfortunately not actively
> working on the tracker lately (just look at how much time it took me to
> respond to your mail!).
> 
> A good start would be to modify the database so that we can record the
> origin of each subscription. I imagine it would be a simple text value
> associated to the subscription: "manual:web" or "manual:email" for a
> manual subscription from the web interface or from the email interface. Or
> "auto:uploaders" for this new feature.
> 
> You will have to modify the Subscription model in
> distro_tracker/core/models.py and you probably want to create a new
> task in distro_tracker/core/retrieve_data.py (or modify an existing one?)
> to create/delete the subscriptions as appropriate.
> 
> You will have to review the places where the subscriptions are created
> and add the required origin value.
> 
> The task should be smart enough to detect when the given email already
> gets the package notifications through a tracker team or through a 
> pre-existing
> (manual) subscription or through an alternate email associated to the same
> user.

1. ^ here

Thanks for the tips! Not sure when I'll get to it, but it'll probably be
before I package anything golang-* because I really do not want to
subscribe to the Go team mailing list nor manage my PTS subscriptions
manually.

Thanks and regards
Afif


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

Bug#926556: unblock: yubikey-personalization/1.19.3-3

[Afif Elghraoui]

Control: tag -1 - moreinfo

Hello,

On Sat, 25 May 2019 13:06:36 -0400 Bill Blough  wrote:
> It appears that the needed changes are located in Salsa [1], and that the
> release was prepared but not uploaded (since it's nowhere to be found).
> 

Indeed. It also looks like he prepared the package and debdiff before
pushing to salsa, because he merged in a pre-existing commit by a
co-maintainer removing his name from the Uploaders list. I've uploaded
the state of salsa as is, so I hope that extra change of dropping an
Uploader isn't an issue.


> This package is team maintained, and since it's not clear to me if the
> rest of the team is aware of this issue, I'm CC'ing the team address in
> this message.
> 
> If there's no response from nicoo or the rest of the team, I would like to go
> ahead with an NMU, assuming that's permissible under these circumstances.
> 

Thanks for following up.

regards
Afif

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

Bug#903635: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Afif Elghraoui]

Hi, Arnaud

On Fri, 10 May 2019 09:03:41 +0700 Arnaud Rebillout
 wrote:>
> As I mentioned above, there's a discussion with a work in progress to
> fix that upstream: https://github.com/docker/libnetwork/pull/2339
> 
> I don't think it will be ready in time for buster though. So I see two
> solutions going forward:
> 
> - 1 Jonathan lower the severity of the bug so that it's not RC.
> 
> - 2 I import the patch from github, even though it's work in progress. I
> will follow up and update the patch as soon as upstream release a proper
> fix, and it will be included in a point release of buster.
> 
> If I don't get any feedback from you Jonathan in the following days,
> I'll go for solution number 2 then.
> 

You hadn't Cc'd Jonathan (but I am, now) and I doubt that he's
subscribed to this bug, so he probably never saw these messages. I'm
just checking in here as a concerned maintainer of a reverse-dependency
threatened with autoremoval.

thanks and regards
Afif

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

Bug#929011: unblock singularity-container - unstable vs testing-proposed-updates

[Afif Elghraoui]

Hello,

To add on to this bug report--- singularity-container is a Go package,
so its dependencies are statically linked (similar concerns as what
happened with docker.io in #927189 [1]). Should I upload to buster?

thanks and regards
Afif

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927189

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

Bug#929042: singularity-container: CVE-2019-11328)

[Afif Elghraoui]

On May 15, 2019 5:13:24 PM EDT, Salvatore Bonaccorso  wrote:
>Hi Afif,
>
>On Wed, May 15, 2019 at 10:57:49PM +0200, Salvatore Bonaccorso wrote:
>> Then there is nothing further to be done.
>
>Oh, actually there is an open point: Is it confirmed that 3.0.3 is not
>affected by the CVE? Did you got any information why this is only
>introduced in 3.1.0?
>

Ok, I asked upstream and the answer is that the commit that introduced the bug 
came after 3.0.3.

regards
Afif

Bug#929042: closed by Afif Elghraoui (Re: Bug#929042: singularity-container: CVE-2019-11328)

[Afif Elghraoui]

على ١٠‏/٩‏/١٤٤٠ هـ ‫٥:١٣ م، كتب Salvatore Bonaccorso:
> Hi Afif,
> 
> On Wed, May 15, 2019 at 10:57:49PM +0200, Salvatore Bonaccorso wrote:
>> Then there is nothing further to be done.
> 
> Oh, actually there is an open point: Is it confirmed that 3.0.3 is not
> affected by the CVE? Did you got any information why this is only
> introduced in 3.1.0?
> 

The release notes say >=3.1.0. The bulk of the patches are in sources
having to do with the oci runtime, which was introduced in 3.1.0. That
would explain the cutoff described by upstream.

In any case, this will hopefully be moot if we can unblock the version
now in Unstable.

regards
Afif

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

Bug#929042: closed by Afif Elghraoui (Re: Bug#929042: singularity-container: CVE-2019-11328)

[Afif Elghraoui]

على ١٠‏/٩‏/١٤٤٠ هـ ‫٤:٥٧ م، كتب Salvatore Bonaccorso:
>>> Could you furthermore check, is this only introduced in the 3.1.0
>>> series really or just are those the versions checked for the issue,
>>> but earlier versions might be affected as well?
>>>
>> I filed an unblock request to hopefully replace 3.0.3 in Testing. 2.6.1 
>> doesn't have the affected code (it predates the Go implementation).
> Thanks that was important bit to know.

That request is here, by the way:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929011

But my reason for making it had nothing to do with this CVE.

regards
Afif

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

Bug#921800: nvchecker: FTBFS (failing tests)

[Afif Elghraoui]

On February 8, 2019 7:59:10 PM EST, Santiago Vila  wrote:
>> It looks like a network access problem. The whole point of this
>> package is to check online sources, so it's hard to test it without
>> network access. I was able to build it just fine in my schroot, but I
>> may have to disable the tests so the buildds can operate...
>
>If you have to do that, please do so.

fair enough

> Packages must not use the
>network during the build, other than installing the build-dependencies.
>This is actually written in Release Policy.
>
>Think about somebody building packages in a desert island and the
>package failing because it can't connect to the outside world.
>
>However, I don't deliberately disable network access in my
>autobuilders, so if just by looking at my build log you remembered
>that your package was doing network access, that's a good thing anyway
>:-)
>
>[ While we are at it, please try uploading in source-only form
>  (dpkg-buildpackage -S). It helps me a lot by preventing certain kind
>  of bugs to propagate to testing (where I usually do my test builds).
> This also creates and keeps archived official build logs for the "all"
>  architecture ].
>

I'm with you. I always do so whenever I can, but this was the first upload and 
needed to be a binary upload to go through NEW...

regards
Afif

Bug#921800: nvchecker: FTBFS (failing tests)

[Afif Elghraoui]

Hello,

On February 8, 2019 7:15:55 PM EST, Santiago Vila  wrote:
>Package: src:nvchecker
>Version: 1.3-1
>Severity: serious
>Tags: ftbfs
>
>Dear maintainer:
>
>I tried to build this package in buster but it failed:
>
>
[...]
>
>async with session.get(url) as res:
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>_ _ _ _ 
>
>self = 0x7f4ba58c7c50>
>
>async def __aenter__(self):
>> return await to_asyncio_future(client.fetch(self.req))
>E tornado.httpclient.HTTPClientError: HTTP 502: Proxy Error
>
>nvchecker/source/tornado_httpclient.py:62: HTTPClientError
...
>The build was made in my autobuilder with "dpkg-buildpackage -A"
>and it also fails here:
>
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nvchecker.html
>
>where you can get a full build log if you need it.
>
>If this is really a bug in one of the build-depends, please use
>reassign and affects,
>so that this is still visible in the BTS web page for this package.
>

It looks like a network access problem. The whole point of this package is to 
check online sources, so it's hard to test it without network access. I was 
able to build it just fine in my schroot, but I may have to disable the tests 
so the buildds can operate...

regards
Afif

Bug#911921: yubikey-manager: diff for NMU version 2.0.0-0.1

[Afif Elghraoui]

Hi, nicoo!

Good to hear from you.


On February 7, 2019 4:26:13 PM EST, Nicolas Braud-Santoni  
wrote:
>On Sat, Feb 02, 2019 at 10:27:33PM -0500, Afif Elghraoui wrote:
>> I've prepared an NMU for yubikey-manager (versioned as 2.0.0-0.1) and
>> uploaded it to DELAYED/7. Please feel free to tell me if I
>> should delay it longer.
>
>Hi Afif!
>
>Thanks a lot for taking care of this.
>
>Unfortunately, I somehow entirely missed the bug and NMU, and prepared
>an upload for 2.0.0 tonight too.  I'm really sorry for wasting your
>effort  :(
>

I needed to use it last week, so I updated the package and used my private 
build to get my work done, so it wasn't totally wasted.


>I hope you don't mind, but I dropped your upload from the delayed queue
>for
>a couple of reasons :
>
>- There was a snafu where Yubico accidentally released different
>upstream
>tarballs on Github and their own site, and I was unsure which you
>uploaded.

Oh, I see. I uploaded the one that you configured uscan to retrieve and verify. 
My fork on salsa also had the pristine-tar branch updated.

https://salsa.debian.org/afif/yubikey-manager


>
>- My upload also contains a bunch of extra changes; nothing major, but
>small
>  improvements, bumping Standards-Version, ...
>

Ok, I hope you also re-enabled the test suite.

>If you would be interested in co-maintaining yubikey-manager (and/or
>other
>related packages), I could invite you to the pkg-auth team  :)
>

I requested to be added to the team pretty early on in my correspondence and 
didn't get any response.

I also uploaded to stretch-backports, so having access to the repo to commit 
the backports branches would be great.

>
>Be st,
>
>  nicoo
>
>PS: Don't hesitate to pester me over IRC; I've been terrible at email
>lately.
>Name is nicoo on OFTC or freenode.

Cool. I haven't been an IRC guy, but that may change. 

btw, the yubico people were looking for you on github (I think in relation to 
yubioauth-desktop).

regards

Afif

Bug#875404: src:gridengine - worked around FTBFS by excluding jgdi

[Afif Elghraoui]

Control: retitle -1 cannot build jgdi with recent Java: sun.rmi.server
Control: severity -1 wishlist
Control: tag -1 - ftbfs

The part of the package that fails to build with recent Java versions is
JGDI. Without a proper patch to fix JGDI, I've excluded it for now (in
gridengine/8.1.9+dfsg-9) [1]. We build the rest of gridengine without
it, so it no longer causes the whole package to FTBFS, so I've lowered
the severity.

In the event of this bug being fixed, the commit [1] should be reverted
to re-enable building and shipping jgdi.

1.
https://salsa.debian.org/hpc-team/gridengine/commit/ac79ef75c32e5faf96c5ca8c618955d4c72ffd61

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

Bug#886810: yubioath-desktop: New upstream release: 4.3.2

[Afif Elghraoui]

On Thu, 24 Jan 2019 09:43:56 -0500 Matt Horan  wrote:
> I opened an upstream issue [1], since three of the four package
> uploaders look to be Yubico employees. I hope that this can be fixed
> before the freeze, as I'd hate to lose this program.
> 
> [1] https://github.com/Yubico/yubioath-desktop/issues/328
> 
> 

According to
https://github.com/Yubico/yubioath-desktop/issues/328#issuecomment-457492367
from that ticket, Yubico is no longer involved in preparing the official
Debian packages. So looks like the names of all the uploaders from
Yubico should be removed, leaving only Simon Josefsson.

regards
Afif

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

Bug#351856: auto-subscription - perhaps reportbug is a better place to implement this

[Afif Elghraoui]

على ٢٨‏/٥‏/١٤٤٠ هـ ‫١:٥٧ ص، كتب Afif Elghraoui:
> Control: subscribe -1 !
> 

silly me--- I mistook this for a control command since I usually use
devscripts' `bts subscribe ...`.

Never mind my previous message and apologies for the noise.

regards
Afif

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

Bug#756954: subscription by uploaders

[Afif Elghraoui]

Control: subscribe -1

Hello,

I was just about to file a bug about this and found it already existing.

The way I was hoping this could work is that Uploaders are automatically
subscribed. I don't know of any reason why an Uploader should not be
following their packages. I think it would also motivate people who
really don't co-maintain a package to get themelves removed from the
Uploaders list, thereby correcting the package metadata.

I think this would also be simpler to implement than subscription
keywords in d/control (as mentioned in the OP). If it's still too far
out of you way, I'd be willing to implement a patch, but would
appreciate a tip about where to look in the code-base. I looked around
it and couldn't find a good starting point in the file hierarchy.

thanks and regards
Afif

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

Bug#911921: yubikey-manager new upstream version

[Afif Elghraoui]

على ٢٠‏/٥‏/١٤٤٠ هـ ‫٨:٣٥ م، كتب Afif Elghraoui:
> Hello,
> 
> Is anyone about to update this package or is any help needed? The
> current upstream version is now 2.0.0.
> 

There have been three new upstream releases since the last upload of
this package that add support for the newer keys.

I had requested to be added to the auth team so I could help with the
maintenance a little. Barring that and doing a team upload, I'm going to
prepare a NMU for this package.

regards
Afif

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



signature.asc
Description: OpenPGP digital signature

Bug#921014: RM: singularity-container [mips mips64el mipsel] -- ROM; no longer builds

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal

singularity-container was recently rewritten in Go and this new code base
is not building on the named architectures. I'd like to prevent this
situation from blocking migration to Testing.

thanks and regards
Afif

Bug#911921: yubikey-manager new upstream version

[Afif Elghraoui]

Hello,

Is anyone about to update this package or is any help needed? The 
current upstream version is now 2.0.0.


regards
Afif

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

Bug#919748: ITP: nvchecker -- new-version checker for software releases

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Afif Elghraoui 

* Package name: nvchecker
  Version : 1.3
  Upstream Author : lilydjwg 
* URL : https://github.com/lilydjwg/nvchecker
* License : MIT
  Programming Lang: Python
  Description : new-version checker for software releases

 nvchecker (short for new version checker) is for checking if a new
 version of some software has been released.


This is a nice vendor-neutral solution for release monitoring. I think it
can also be quite useful in research, for example, to watch for updates of all
tools used in an analysis. And it doesn't have to be limited to watching
software releases, either. It could be applied to watching updates in
reference databases.

I intend to maintain nvchecker in the Debian group on salsa.

Afif

Bug#875404: gridengine and java

[Afif Elghraoui]

Control: tag -1 + help

status update on this bug:

I tried to get the build working months ago with the java10 branch on 
Salsa [1]. The current issue is an error when trying to use jemalloc, 
which I've reported upstream [2]. the error is


[java] [java] 
/<>/gridengine-8.1.9+dfsg/source/libs/jgdi/build.xml:495: 
java.lang.UnsatisfiedLinkError?: 
/<>/gridengine-8.1.9+dfsg/source/LINUXAMD64/libdrmaa.so: 
/usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory in 
static TLS block


and more details (including the build log) are on the upstream ticket [2].


1. https://salsa.debian.org/hpc-team/gridengine/tree/java10
2. https://arc.liv.ac.uk/trac/SGE/ticket/1642

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

Bug#919026: singularity-container: implausibly old timestamps when creating containers

[Afif Elghraoui]

Package: singularity-container
Version: 2.4-1
Severity: normal
Control: forwarded -1 https://github.com/sylabs/singularity/issues/1271

$  singularity exec docker://busybox whoami
Docker image path: index.docker.io/library/busybox:latest Cache folder set to 
/home/hayashis/.singularity/docker Creating container runtime... tar: ./.exec: 
implausibly old time stamp -9223372036854775808 tar: ./.run: implausibly old 
time stamp -9223372036854775808 tar: ./.shell: implausibly old time stamp 
-9223372036854775808 tar: ./.singularity.d/actions/exec: implausibly old time 
stamp -9223372036854775808 tar: ./.singularity.d/actions/run: implausibly old 
time stamp -9223372036854775808 tar: ./.singularity.d/actions/shell: 
implausibly old time stamp -9223372036854775808 tar: 
./.singularity.d/actions/start: implausibly old time stamp -9223372036854775808 
tar: ./.singularity.d/actions/test: implausibly old time stamp 
-9223372036854775808 tar: ./.singularity.d/actions: implausibly old time stamp 
-9223372036854775808 tar: ./.singularity.d/env/01-base.sh: implausibly old time 
stamp -9223372036854775808 tar: ./.singularity.d/env/90-environment.sh: 
implausibly old time stamp -9223372036854775808 tar: 
./.singularity.d/env/95-apps.sh: implausibly old time stamp 
-9223372036854775808 tar: ./.singularity.d/env/99-base.sh: implausibly old time 
stamp -9223372036854775808 tar: ./.singularity.d/env: implausibly old time 
stamp -9223372036854775808 tar: ./.singularity.d/libs: implausibly old time 
stamp -9223372036854775808 tar: ./.singularity.d/runscript: implausibly old 
time stamp -9223372036854775808 tar: ./.singularity.d/startscript: implausibly 
old time stamp -9223372036854775808 tar: ./.singularity.d: implausibly old time 
stamp -9223372036854775808 tar: ./.test: implausibly old time stamp 
-9223372036854775808 tar: ./dev: implausibly old time stamp 
-9223372036854775808 tar: ./environment: implausibly old time stamp 
-9223372036854775808 tar: ./etc/hosts: implausibly old time stamp 
-9223372036854775808 tar: ./etc/resolv.conf: implausibly old time stamp 
-9223372036854775808 tar: ./etc: implausibly old time stamp 
-9223372036854775808 tar: ./home: implausibly old time stamp 
-9223372036854775808 tar: ./proc: implausibly old time stamp 
-9223372036854775808 tar: ./root: implausibly old time stamp 
-9223372036854775808 tar: ./singularity: implausibly old time stamp 
-9223372036854775808 tar: ./sys: implausibly old time stamp 
-9223372036854775808 tar: ./tmp: implausibly old time stamp 
-9223372036854775808 tar: ./var/tmp: implausibly old time stamp 
-9223372036854775808 tar: ./var: implausibly old time stamp 
-9223372036854775808 tar: .: implausibly old time stamp -9223372036854775808 
user


This issue was reported upstream, but it's a debian bug introduced by an error 
in the reproducibile-builds patch from . That 
patch was applied in version 2.4-1 and affects all successive versions.

libexec/bootstrap-scripts/environment/Makefile.am is patched to call tar with 
the flag `--mtime="@${SOURCE_DATE_EPOCH:-$(date +%s)}"`, but the dollar sign 
isn't escaped in the patch, so Make just sees --mtime="@" and substitutes the 
implausibly old mtime for this invalid one.

Bug#917867: singularity-container: not supportable for Stable

[Afif Elghraoui]

Package: singularity-container
Version: 2.6.1-1
Severity: serious

singularity-container previously had to be removed from stretch [1] due to the
unfeasibility of security support for that version [private communication with
security team and upstream]. While upstream has gotten better about marking
vulnerable versions of the software and using CVEs, it turns out that security
support will remain unfeasible [2]. Security support for the community is only
promised by upstream for the latest release [3]. Therefore,
singularity-container should be blocked from testing so that it does not enter
a stable release.

1. https://bugs.debian.org/898154
2. https://lists.debian.org/debian-hpc/2018/12/msg00029.html
3. https://www.sylabs.io/singularity/

--
Afif Elghraoui

Bug#912586: [Debian-med-packaging] Bug#912586:

[Afif Elghraoui]

على ٢٣‏/٢‏/١٤٤٠ هـ ‫١١:٠٤ م، كتب Michael Hudson-Doyle:



On Fri, 2 Nov 2018 at 15:30, Afif Elghraoui <mailto:a...@debian.org>> wrote:




على ٢٣‏/٢‏/١٤٤٠ هـ ‫٩:٥٣ م، كتب Michael Hudson-Doyle:
 > I don't understand this change:
 >

https://salsa.debian.org/med-team/python-cobra/commit/1ec0fba3fea202b38044e3497edf033ef94a31e3
 >
 > AFAICT, it's just wrong. But maybe I'm missing something.
 >

At one point a long time ago, the test suite would return True if
successful, which translated into an exit code of 1 and interpreted as
failure. I don't know whether that's still the case.

Not according to the docs: 
https://docs.pytest.org/en/latest/usage.html#calling-pytest-from-python-code




Back in 2016, it looked like this:

https://github.com/opencobra/cobrapy/blob/515cbaa71de74823b3a0c9fcaeff839618d47207/cobra/test/__init__.py#L42

I'm just explaining the commit in the packaging repository because I 
authored it back then. Not saying it needs to stay that way.


Afif

Bug#912586: [Debian-med-packaging] Bug#912586:

[Afif Elghraoui]

على ٢٣‏/٢‏/١٤٤٠ هـ ‫٩:٥٣ م، كتب Michael Hudson-Doyle:
I don't understand this change: 
https://salsa.debian.org/med-team/python-cobra/commit/1ec0fba3fea202b38044e3497edf033ef94a31e3


AFAICT, it's just wrong. But maybe I'm missing something.



At one point a long time ago, the test suite would return True if 
successful, which translated into an exit code of 1 and interpreted as 
failure. I don't know whether that's still the case.


regards
Afif

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

Bug#912175: RM: ori -- ROM; unmaintained upstream and not fit for release

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal


The latest upstream commit is from late 2016 [1]. The RC bug related to openssl 
1.1 has never been addressed [2,3].

regards
Afif


1. https://bitbucket.org/orifs/ori/commits/all
2. https://bugs.debian.org/828481
3. https://bitbucket.org/orifs/ori/issues/22/ftbfs-with-openssl-110

Bug#828481: ori: FTBFS with openssl 1.1.0

[Afif Elghraoui]

على ٣‏/٢‏/١٤٤٠ هـ ‫٤:٣٣ م، كتب Moritz Mühlenhoff:

On Fri, Oct 13, 2017 at 12:52:55AM -0400, Afif Elghraoui wrote:





What's the status? ori hasn't been uploaded since 21 months, is there
any progress?



There's been no development activity upstream since then either. I think 
it's time I filed for this package's removal.


regards
Afif

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

Bug#898034: Acknowledgement (adduser: [INTL:de] updated German debconf translation)

[Afif Elghraoui]

Hi, Helge

على السبت 15 أيلول 2018 ‫08:08، كتب Helge Kreutzmann:
> Do you have any ETA for including the German Debconf translation? 
> 
> Since this is a central package it would be great if German speaking
> users could see the localiized prompts.
> 
> I see that als the dutch and french translations are pending.
> 
> If you want, I can do an NMU just with the three translations, but I
> assume you are doing a MU instead?

I had actually removed my name from the adduser uploaders. Since I never
made an upload to realize that change, I can add these translations as
part of it and do this today.

regards
Afif

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

Bug#902132: [Debian-med-packaging] Bug#902132: falcon: FTBFS since python-networkx version 2.1-1; fails in test suite

[Afif Elghraoui]

Hello,

On September 12, 2018 5:30:59 AM EDT, Andreas Tille  wrote:
>Hi Alex,
>
>On Wed, Sep 12, 2018 at 10:55:20AM +0200, Alex Mestiashvili wrote:
>> Well, according upstream, current repository is not active anymore:
>> 
>> 
>> Oh, sorry. We are no longer mirroring our internal FALCON repo here.
>In
>> fact, I think this Issues board will disappear soon too, in favor of
>> pbbioconda. So I think your source-code is way out of date.
>> Unfortunately, my hands are tied.
>> 
>> https://github.com/PacificBiosciences/FALCON/issues/672
>
>Thanks for your research on this issue.
> 
>> I am not sure how to get the source from pbbioconda and if this
>source
>> is suitable for packaging at all.
>
>I added a comment to the issue above where I've found a link inside the
>bioconda metadata[1] (assuming this is what upstream was refereing to).
>We can surely package where those meta.yaml files are pointing to but
>see my comments.
>
>It would be extremely helpful if we would find somebody at PacBio who
>can explain the situation (Afif?  I know you said you are not using the
>pb* software any more, but can you possibly help out?).  As I wrote on
>Monday[2] I have another issue with a lib from there.
>

The pbbioconda being referred to looks like 
https://github.com/PacificBiosciences/pbbioconda
and the README there lists all their packages and links to their main bioconda 
pages.

Andreas, I think the pb-falcon you found is the right one as far as I can tell.

regards
Afif


> 
>
>[1]
>https://github.com/bioconda/bioconda-recipes/blob/master/recipes/pb-falcon/meta.yaml
>[2] https://lists.debian.org/debian-mentors/2018/09/msg00152.html
>
>-- 
>http://fam-tille.de

Bug#903015: stretch-pu: package gridengine/8.1.9+dfsg-4

[Afif Elghraoui]

On July 9, 2018 12:18:06 PM EDT, "Adam D. Barratt"  
wrote:
>On 2018-07-09 04:16, Afif Elghraoui wrote:
>> على الأحد  8 تـمـوز 2018 ‫14:38، كتب Adam D. Barratt:
>>> 
>
>I've filed #903406 with a small patch that at least builds successfully
>
>on abel.d.o.
>
>If you could upload a +deb9u2 including that patch shortly (ideally 
>today) then we should still be able to get the update into this 
>weekend's point release. (Alternatively I can upload it, but I'd prefer
>
>having maintainer buy-in, as I don't really want to have to support it 
>afterwards. ;-) )
>

Thanks. I haven't looked at the patch yet, but I should get to this hopefully 
tonight.

regards
Afif

Bug#903015: stretch-pu: package gridengine/8.1.9+dfsg-4

[Afif Elghraoui]

على الأحد  8 تـمـوز 2018 ‫14:38، كتب Adam D. Barratt:
> 
> Unfortunately, the build failed on armhf:
> 
> 
>  [java]  [exec] /usr/bin/ld: cannot find -ljvm
>  [java]  [exec] collect2: error: ld returned 1 exit status
>  [java]  [exec] make[2]: *** [jgdi_test] Error 1
> 
> BUILD FAILED
> /<>/gridengine-8.1.9+dfsg/source/build.xml:85: The following error 
> occurred while executing this line:
> /<>/gridengine-8.1.9+dfsg/source/build.xml:30: Java returned: 1
> 
> 
> Looking at buildd.d.o, this seems to have been happening in unstable
> for a few months now as well, but I can't find a related bug report.
> Any idea what's going on here?
> 

I asked the java team about this in December [1] and never heard back.
It seemed to me that the path to the openjdk libraries on armhf changed
so that the gridengine build system wasn't looking in the right place
anymore and thought the java team would know more about it. I didn't
pursue it further, though.


regards
Afif

1. https://lists.debian.org/debian-java/2017/12/msg00050.html

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

Bug#903015: stretch-pu: package gridengine/8.1.9+dfsg-4

[Afif Elghraoui]

على السبت  7 تـمـوز 2018 ‫07:35، كتب Adam D. Barratt:
> With the above change, please feel free to upload.

Uploaded. I hope source-only is fine.

Thanks and regards
Afif

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

Bug#903192: [Debian-med-packaging] Bug#903192: sniffles: FTBFS in buster/sid (dh_installman: Cannot find "debian/sniffles.1")

[Afif Elghraoui]

Hi, Santiago

على السبت  7 تـمـوز 2018 ‫07:40، كتب Santiago Vila:
> The build was made with "dpkg-buildpackage -B" in my autobuilder.
> (This one does not seem to fail with plain "dpkg-buildpackage")
> 
> [ Note: There has been a recent change in debhelper behaviour, the current
>   behaviour is the intended one. See Bug #903133 for details ].

This is very strange, firstly because the behavior is different with or
without `-B` despite the source package not defining any arch:all binary
packages to begin with.

The error seems to be because the manpage is defined in debian/manpages,
but is created during the package build. I've worked around that, but
it's still curious why the error is not consistent without `-B`.

regards
Afif

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

Bug#903015: stretch-pu: package gridengine/8.1.9+dfsg-4 - complete diff

[Afif Elghraoui]

Here is the complete diff for the proposed upload, including the changelog:

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+gridengine (8.1.9+dfsg-4+deb9u1) stretch-proposed-updates; urgency=medium
+
+  * gridengine-qmon:
+  - Use correct paths to qmon pixmaps (Closes: #892296)
+
+ -- Afif Elghraoui   Thu, 05 Jul 2018 00:38:58 -0400
+
 gridengine (8.1.9+dfsg-4) unstable; urgency=low

   * Patch upstream source to declare prerequisites for pdc (Closes:
#846770)
diff --git a/debian/gridengine-qmon.install b/debian/gridengine-qmon.install
index 99b6cf17d..59ddc17f0 100644
--- a/debian/gridengine-qmon.install
+++ b/debian/gridengine-qmon.install
@@ -1,2 +1,2 @@
 debian/tmp/usr/bin/*/qmon  usr/lib/gridengine
-debian/tmp/usr/qmon/PIXMAPS/*  usr/share/gridengine/pixmaps
+debian/tmp/usr/qmon/PIXMAPSusr/share/gridengine/qmon/
diff --git a/debian/gridengine-qmon.links b/debian/gridengine-qmon.links
index cefcd72ed..ecaf1fda2 100644
--- a/debian/gridengine-qmon.links
+++ b/debian/gridengine-qmon.links
@@ -1 +1,2 @@
 usr/share/gridengine/gridengine-wrapper usr/bin/qmon
+usr/share/gridengine/qmon/PIXMAPS  var/lib/gridengine/qmon/PIXMAPS

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

Bug#903015: stretch-pu: package gridengine/8.1.9+dfsg-4

[Afif Elghraoui]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

A user requested that the bug #892296 be fixed in Stable [1].
The necessary patch to fix this is at the end of this message.

Thanks and regards
Afif

1. https://lists.debian.org/debian-hpc/2018/06/msg00021.html

>From c416d2f88fa6ee1518d95e37a65856c571994bc0 Mon Sep 17 00:00:00 2001
From: Afif Elghraoui 
Date: Sun, 11 Mar 2018 17:07:27 -0400
Subject: [PATCH] Use correct paths to qmon pixmaps

Closes: #892296
---
 debian/gridengine-qmon.install | 2 +-
 debian/gridengine-qmon.links   | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/gridengine-qmon.install b/debian/gridengine-qmon.install
index 99b6cf17d..59ddc17f0 100644
--- a/debian/gridengine-qmon.install
+++ b/debian/gridengine-qmon.install
@@ -1,2 +1,2 @@
 debian/tmp/usr/bin/*/qmon  usr/lib/gridengine
-debian/tmp/usr/qmon/PIXMAPS/*  usr/share/gridengine/pixmaps
+debian/tmp/usr/qmon/PIXMAPSusr/share/gridengine/qmon/
diff --git a/debian/gridengine-qmon.links b/debian/gridengine-qmon.links
index cefcd72ed..ecaf1fda2 100644
--- a/debian/gridengine-qmon.links
+++ b/debian/gridengine-qmon.links
@@ -1 +1,2 @@
 usr/share/gridengine/gridengine-wrapper usr/bin/qmon
+usr/share/gridengine/qmon/PIXMAPS  var/lib/gridengine/qmon/PIXMAPS
-- 
2.18.0

Bug#900485: [Debian-med-packaging] Bug#900485: python-pbcore: FTBFS and Debci failure with NumPy 1.14

[Afif Elghraoui]

On June 26, 2018 3:45:49 AM EDT, Andreas Tille  wrote:
>On Mon, Jun 25, 2018 at 09:52:50AM -0400, Afif Elghraoui wrote:
>> I think we can give 1.5.0 a try, but it might have the same problem.
>
>Since it builds successfully I've just uploaded.
> 

Ok

>> >  (And what do you think about watch mode=git?)
>> 
>> I don't know much about it, but I don't have any strong preference
>here.
>
>It might serve as a sensible solution for all upstreams using Git
>without proper release tagging.  I guess the pbcore example will
>explain
>what to do.
> 
>BTW, I remembered to late that you are not happy about the cme
>formatting.  I just fired up cme for Vcs-fields, Standards-Version etc.
>I hope you don't mind - feel free to revert to your prefered formatting
>and I hope I will not forget if I touch some of your packages in
>future.
>

Don't worry about this.

>
>PS: I'm currently checking pbseqlib since now upstream has tagged a
>release but there are some hdf5 issues which prevent me from
>uploading.  Please let me know if you want me to revert the cme
>formatting to its previous shape.
>

No need to revert anything.

regards
Afif

Bug#900485: [Debian-med-packaging] Bug#900485: python-pbcore: FTBFS and Debci failure with NumPy 1.14

[Afif Elghraoui]

On June 25, 2018 5:07:48 AM EDT, Andreas Tille  wrote:
>Hi Afif,
>
>On Mon, Jun 25, 2018 at 03:41:11AM -0400, Afif Elghraoui wrote:
>> >pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>> >/tmp/tmpveTAsa.subreadset.xml
>> >
>> >Before I start diving into this:  Afif, upstream seems to have
>released
>> >1.5.0 which might be worth a try.  While I asked for creating
>according
>> >release tags[2] I remember you said that upstream does not care much
>> >about this metadata.  I wonder whether we should possibly use
>mode=git
>> >inside the watch file, inject version 1.5.0 into packaging Git,
>cross
>> >fingers that the issue might be fixed and if not report the issue
>> >upstream.
>> >
>> 
>> I believe that error had to do with the package requiring an older
>version of some dependency. At least, the error I was seeing at the
>time was for that reason, which prevented me from uploading.
>
>So we can either skip those tests (no idea how important is this for
>general functionality) or give 1.5.0 a try.  What do you think is
>the better strategy?

I think we can give 1.5.0 a try, but it might have the same problem.

>  (And what do you think about watch mode=git?)
>

I don't know much about it, but I don't have any strong preference here.

regards
Afif

Bug#900485: [Debian-med-packaging] Bug#900485: python-pbcore: FTBFS and Debci failure with NumPy 1.14

[Afif Elghraoui]

Hi, Andreas

On June 25, 2018 3:32:00 AM EDT, Andreas Tille  wrote:
>Hi Graham,
>
>On Sun, Jun 24, 2018 at 08:48:32PM +0200, Graham Inggs wrote:
>> Control: tags -1 + patch
>
>thanks for the patch.  Since we are targeting in Git at version 1.4.2 I
>adapted the patch to this version and it works for this.  I also fixed
>another issue in the test suite[1].  Unfortunately there are remaining
>errors in the test suite which are all connected to a possible issue
>with
>XML files:
>
>$ grep "ERROR: Invalid file produced"
>python-pbcore_1.4.2+dfsg-1_amd64.build 
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpiOHCZI.alignmentset.xml.disabled
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmplAqR2T.alignmentset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpMyWNXh.subreadset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmps4GD0E.subreadset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmp71IS22dataset-unittest/test.alignmentset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpUn37tBdataset unittest/spaced.subreadset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpMouabqdataset-unittest/tempfile.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpN0pUz2alignmentset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpeQ4v3jalignmentset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmp0Kb6RWdataset-doctest/tempfile.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpj20209.subreadset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmp2XGDAY.barcodeset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpXtaXG3.consensusreadset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpJlLjAA.contigset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpDKGXFh.contigset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmptZ4Kro.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmp6ySKmX.contigset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpvYTcX1.subreadset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpiXc1ez.subreadset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpdiSRmI.subreadset.xml
>pbcore.io.dataset.DataSetIO: ERROR: Invalid file produced:
>/tmp/tmpveTAsa.subreadset.xml
>
>
>Before I start diving into this:  Afif, upstream seems to have released
>1.5.0 which might be worth a try.  While I asked for creating according
>release tags[2] I remember you said that upstream does not care much
>about this metadata.  I wonder whether we should possibly use mode=git
>inside the watch file, inject version 1.5.0 into packaging Git, cross
>fingers that the issue might be fixed and if not report the issue
>upstream.
>

I believe that error had to do with the package requiring an older version of 
some dependency. At least, the error I was seeing at the time was for that 
reason, which prevented me from uploading.

regards
Afif
.
>
>[1]
>https://salsa.debian.org/med-team/python-pbcore/blob/master/debian/patches/relax_test_constraint.patch
>[2] https://github.com/PacificBiosciences/pbcore/issues/116
>
>-- 
>http://fam-tille.de
>
>___
>Debian-med-packaging mailing list
>debian-med-packag...@alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

Bug#896642: RM: sniffles [mips hppa powerpc sparc64] -- ROM; does not function

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org

Previous versions of the package did not hae any tests to run. The
latest version now does, and the tests failed on the named
architectures. It has probably never worked with the previous versions
either, and the lack of an updated build on mips is now preventing
migration to testing.

Thanks and regards
Afif

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

Bug#893133: Could we maintain compatibility with older debhelpers to ease backporting

[Afif Elghraoui]

Control: tag -1 + confirmed

Hi, Yaroslav,


>
>Thanks for maintaining and updating the package through the latest
>releases.
>But I wondered -- since you also had similar (minor but still) pains --
>could
>we retain/maintain compatibility with previous versions of debhelper,
>e.g. 10
>(or even better 9, which I believe still supported by debhelper in
>sid).
>

Yes, you're right. I'm sorry about that. Go ahead with 9. I think 10 was still 
causing trouble the way I tried to use it in the jessie-backports-sloppy build.

regards
Afif

Bug#887192: singularity-container should depend on e2fsprogs explicitly

[Afif Elghraoui]

On February 14, 2018 7:04:32 AM EST, Andreas Henriksson  
wrote:
>
>Would be great if you could have this fixed ASAP. If you're busy
>feel free to just ask for help with a non-maintainer upload in
>the meantime and I'll make it happen.
>

For me, that would be maybe tomorrow night. I have no problem with an NMU.

Thanks and regards
Afif

Bug#887192: singularity-container should depend on e2fsprogs explicitly

[Afif Elghraoui]

على الإثنين 12 شباط 2018 ‫12:02، كتب Andreas Henriksson:
> On Sun, Jan 14, 2018 at 08:11:26PM +0100, Helmut Grohne wrote:
>> Package: singularity-container
> [...]
>> /usr/lib/x86_64-linux-gnu/singularity/cli/image.create.exec contains 
>> mkfs.ext3. According to file it is a Bourne-Again shell script, ASCII text 
>> executable
>> /usr/lib/x86_64-linux-gnu/singularity/cli/image.expand.exec contains e2fsck 
>> and resize2fs. According to file it is a Bourne-Again shell script, ASCII 
>> text executable
> [...]
> 
> Looks to me like there should be a dependency added here for sure.
> 
> Would be great to hear from the maintainers on this!
> 

I would say it should rather be a Recommends. The old default container
image format was based on ext3. It's still supported, but it's just one
of a few possible options.

If that's no problem to you, we can go ahead and make it happen.

Thanks and regards
Afif

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

Bug#890220: ITP: assemblytics -- detect and analyze structural variants from a genome assembly

[Afif Elghraoui]

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

* Package name: assemblytics
  Version : 0~20170131
  Upstream Author : Maria Nattestad <mnatt...@cshl.edu>
* URL : http://assemblytics.com
* License : MIT
  Programming Lang: Python, R
  Description : detect and analyze structural variants from a genome
assembly

Assemblytics incorporates a unique anchor filtering approach to increase
robustness to repetitive elements, and identifies six classes of variants
based on their distinct alignment signatures. Assemblytics can be applied
both to comparing aberrant genomes, such as human cancers, to a reference,
or to identify differences between related species.

This will be maintained by Debian Med.

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

Bug#889790: RM: hinge [i386 armel armhf mips mipsel s390x] -- ROM; not installable

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal

Due to the package building on platforms where it's not even
installable, it never migrated. I hacked around this problem again by
copying Depends into Build-Depends and uploading again, but it seems
that the existence of old binaries on these architectures in Unstable
will still prevent migration once the time limit elapses [1].

Thanks and regards
Afif

https://qa.debian.org/excuses.php?package=hinge

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

Bug#889613: ITP: swiglpk -- Plain Python bindings for the GNU Linear Programming Kit

[Afif Elghraoui]

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

* Package name: swiglpk
  Version : 1.4.4
  Upstream Author : The Novo Nordisk Foundation Center for Biosustainability
* URL : https://github.com/biosustain/swiglpk
* License : GPL
  Programming Lang: Python
  Description : Plain Python bindings for the GNU Linear Programming Kit

swiglpk just provides plain SWIG bindings to the underlying C library
of the GNU Linear Programming Kit. It is not a high-level wrapper for GLPK.

This is a dependency of optlang and a new dependency of python-cobra. It
will be maintained by the Debian Science team.

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

Bug#889607: no such package as sse-support, just sse2/3/4.2

[Afif Elghraoui]

Control: tag -1 + moreinfo

Hello,

على الأحد  4 شباط 2018 ‫17:56، كتب Adam Borowski:
> Hi!
>> nanopolish [:i386]
>> The package would not migrate to testing because it was not installable
>> on i386 for lack of sse-support.
> 
> There never was a package by that name.  The only variants are sse2-support
> [any-i386] sse3-support [any-i386 any-amd64] sse4.2-support [any-i386
> any-amd64] and stuff for architectures you're not interested in.
> 
> I really doubt you're looking for sse1 in particular -- I expect your
> package uses a newer variant; a package of this kind doesn't really care
> about CPUs so old anyway, thus the distinction doesn't matter.
> 
> (Note that marking packages that use a non-base CPU extension this way is
> controversial -- but no one implemented a better solution yet.)
> 

Thanks for pointing that out. I have to see what my co-maintainer had in
mind when adding this.

> 
> As for this RM, it won't work as your package still tries to build on i386,
> which will reintroduce nanopolish:i386 as soon as ftpmasters remove it.
> Thus, you'd need to upload a new version first.

I already did an upload before filing this bug, so it's now showing as
BD-Uninstallable on i386.

Thanks and regards
Afif

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

Bug#889611: ITP: optlang -- sympy-based mathematical programming language

[Afif Elghraoui]

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

* Package name: optlang
  Version : 1.3.0
  Upstream Author : Novo Nordisk Foundation Center for Biosustainability
* URL : http://optlang.readthedocs.org/
* License : Apache

  Programming Lang: Python

  Description : sympy-based mathematical programming language

Optlang is a Python package for solving mathematical optimization
problems, i.e. maximizing or minimizing an objective function over a set
of variables subject to a number of constraints. Optlang provides a
common interface to a series of optimization tools, so different solver
backends can be changed in a transparent way. Optlang's object-oriented
API takes advantage of the symbolic math library sympy to allow
objective functions and constraints to be easily formulated from
symbolic expressions of variables (see examples).

This is a new dependency of python-cobra. It will be maintained under
Debian Science.

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

Bug#889607: RM: nanopolish [i386] -- ROM; sse-support not available

[Afif Elghraoui]

Package: ftp.debian.org
Severity: normal

The package would not migrate to testing because it was not installable
on i386 for lack of sse-support.

Thanks and regards
Afif

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

Bug#844377: apt-get and apt also affected?

[Afif Elghraoui]

Hello,

On December 22, 2017 9:14:14 PM EST, Thomas Lange 
 wrote:
>Are apt-get and apt are also affected by the different behaviour when
>using -t release or  package/release?
>

That is how they behave, and your treating them as equivalent is the problem.

>You may want to ask the apt maintainers if they have a solution for
>using a release name without using -t. Or to force a better
>dependency resolution when a packages uses /release.

If you consider this a bug in apt, feel free to reassign.

regards
Afif

Bug#881360: [Debian-med-packaging] Bug#881360: /usr/lib/htslib unused by bcftools anyway

[Afif Elghraoui]

Hi, Andreas,

On December 11, 2017 8:32:53 AM EST, Andreas Tille  wrote:
>Hi Afif,
>
>this message and the previous one hit me in a time of beeing busy with
>other stuff.  I've removed the files in question now and closed the
>bug.
>
>Kind regards
>
>Andreas.
>
>PS: You can always feel free to fix the issue in htslib (or whereever
>you see a problem yourself - that's actually the prefered way to deal
>with this. ;-) )
>

That was what I tried at first. In my original message, I said I wasn't sure if 
your commit immediately following the one that installed the .mk files was also 
related and if it should also have been reverted.

regards
Afif

Bug#864376: falcon: properly fix test failure: Task Node(1-preads_ovl/m_00001) failed with exit-code=256

[Afif Elghraoui]

Hi, Andreas,

On December 11, 2017 6:55:17 AM EST, Andreas Tille  wrote:
>Hi Afif,
>
>there is a new upstream version which I intended to give a chance
>whether this issue might be fixed.  Unfortunately the get-orig-source
>script fails - somehow the submodules are not cloned properly.
>
>Before I'll dive into this, could you please have a look?
>

I think I can. Just give me a few days.

>Thank you
>

You're welcome.

regards
Afif

Bug#883047: [Debian-med-packaging] Bug#883047: canu: Build-depend on mhap to avoid uninstallable binaries

[Afif Elghraoui]

On December 1, 2017 9:12:19 PM EST, Steve Langasek 
<steve.langa...@canonical.com> wrote:
>On Fri, Dec 01, 2017 at 03:37:47AM -0500, Afif Elghraoui wrote:
>>  I believe this is
>primarily
>> an issue with wanna-build queuing the package for building on those
>> architectures to begin with [1].
>
>The behavior of wanna-build is by design and I don't believe it will
>ever
>(or should ever) change.  You are asking that the buildds avoid queuing
>the
>package for build based on the availability of dependencies for the
>binary
>packages /that have not yet been built/.  For wanna-build to introspect
>debian/control and parse the Depends: fields of the binary package
>stanzas
>would be an abstraction violation, given that the vast majority of
>binary
>packages in the archive have dependency fields that are at least partly
>generated at package build time.

They could alternatively be checked post-build, pre-upload.

Anyway, there must be a better solution than abusing the build-depends field, 
but if everyone seems content with this, maybe I'll just start copying all 
Depends into Build-Depends from now on.

Afif

Bug#883047: [Debian-med-packaging] Bug#883047: canu: Build-depend on mhap to avoid uninstallable binaries

[Afif Elghraoui]

Hi, Steve,

On November 29, 2017 12:50:55 AM EST, Steve Langasek 
 wrote:
>In Ubuntu, we observed that the canu package was not releasable because
>it
>generates per-architecture binary packages with a transitive dependency
>on
>libssw-java, which is only available on amd64.
>
>To work around this issue, I have added an "artificial" build
>dependency on
>mhap to the canu package in Ubuntu, so that the package will not build
>on
>architectures where mhap is not available.
>
>This problem also affects canu in Debian, and is the reason that canu
>has
>not migrated to Debian testing;

Yes, as I saw in https://lists.debian.org/debian-release/2017/10/msg00239.html

> so I would suggest applying this patch
>in
>Debian as well.
>

Thanks for your concern. I did not see much interest on this package and so was 
not really interested in a workaround. I believe this is primarily an issue 
with wanna-build queuing the package for building on those architectures to 
begin with [1].

regards
Afif

1. https://lists.debian.org/debian-wb-team/2017/10/msg9.html

Bug#881360: [Debian-med-packaging] /usr/lib/htslib unused by bcftools anyway

[Afif Elghraoui]

Hi, Andreas,

I'm not sure if you saw my message below when I sent it originally. I'd
appreciate if you could take a look at this issue.

regards
Afif

على الثلاثاء 14 تشرين الثاني 2017 ‫10:10، كتب Afif Elghraoui:
> Hi, Andreas,
> 
> On November 14, 2017 7:08:59 AM EST, John Marshall 
> <john.w.marsh...@glasgow.ac.uk> wrote:
>> It appears that since 7 August 2017
>> (0206c3d81e695291f17b780e77e671f95e36860b and
>> 608f125011f3d275806598d0093526218dbfc9bf), Debian's bcftools build no
>> longer uses /usr/lib/htslib anyway:
>>
>> bcftools (1.5-1~exp1) experimental; urgency=medium
>>
>>  [ Afif Elghraoui ]
>>  * Update packaging for new build system
>> [snip]
>> -- Afif Elghraoui <a...@debian.org>  Mon, 07 Aug 2017 20:06:52 -0400
>>
>>
> 
> Would you mind reverting the problematic changes to the htslib packaging to 
> resolve this issue? I took a look at it a few days ago, but it doesn't git 
> revert cleanly and I wasn't sure if the following commit you made was also 
> related.
> 
> Thanks and regards
> Afif
> 

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

Bug#881360: [Debian-med-packaging] Bug#881360: /usr/lib/htslib unused by bcftools anyway

[Afif Elghraoui]

Hi, Andreas,

On November 14, 2017 7:08:59 AM EST, John Marshall 
<john.w.marsh...@glasgow.ac.uk> wrote:
>It appears that since 7 August 2017
>(0206c3d81e695291f17b780e77e671f95e36860b and
>608f125011f3d275806598d0093526218dbfc9bf), Debian's bcftools build no
>longer uses /usr/lib/htslib anyway:
>
>bcftools (1.5-1~exp1) experimental; urgency=medium
>
>  [ Afif Elghraoui ]
>  * Update packaging for new build system
>[snip]
>-- Afif Elghraoui <a...@debian.org>  Mon, 07 Aug 2017 20:06:52 -0400
>
>

Would you mind reverting the problematic changes to the htslib packaging to 
resolve this issue? I took a look at it a few days ago, but it doesn't git 
revert cleanly and I wasn't sure if the following commit you made was also 
related.

Thanks and regards
Afif

Bug#827076: Processed: raise severity of openssl-1.1-trans blockers

[Afif Elghraoui]

On November 13, 2017 2:43:16 PM EST, ow...@bugs.debian.org wrote:
>Processing commands for cont...@bugs.debian.org:
>
>> # Raising the severity of bugs which are blocking the removal of
>> # libssl1.0.2 which we want gone for Buster.
>> # https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871056#55
>> #
>> # src:gridengine: FTBFS with openssl 1.1.0
>> severity 827076 serious
>Bug #827076 [src:gridengine] src:gridengine: FTBFS with openssl 1.1.0
>Bug #828329 [src:gridengine] gridengine: FTBFS with openssl 1.1.0
>Severity set to 'serious' from 'important'
>Severity set to 'serious' from 'important'

There are patches to resolve this ticket, but I thought I'd wait for the 
possibility of a new upstream release that would incorporate them. Since that 
hasn't happened, I'll just add the patches the next time I get a chance.

Afif

Bug#879886: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

On November 9, 2017 6:20:03 PM EST, Diane Trout  wrote:
>
[...]
>
>Anyone want to review? or should I go ahead and release?
>

I think you can release. However, it appears the changelog wasn't updated in 
git since the last upload [1] you'll need to go for a 1.5-3.

regards
Afif

1. 
http://metadata.ftp-master.debian.org/changelogs/main/h/htslib/htslib_1.5-2_changelog

Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

On November 9, 2017 3:06:32 AM EST, Mattia Rizzolo  wrote:
>On Wed, Nov 08, 2017 at 04:58:49PM -0800, Diane Trout wrote:
>> > > I was wondering if we should split the cram headers into a
>> > > libhts-private-dev so we can at least track what is depending on
>> > > the
>> > > non-public api.
>
>Can I recommend dealing with the public/non-public API *after* adding
>the symbols file and doing other general stuff?

+1

>
>In general, I recommend against doing dozens of (possibly hard, like in
>this case) changes in a single huge upload, let's split them out :)
>
>Upstream kindly opened #881170 to track other issues as well, perahps
>clone that bug to track all those issues separately (as they all
>require
>changes to other packages, so need to be coordinated separately, and
>need not to be done at the same time either).

Also +1
>
>
>If you find issues getting stuff sponsored, please do point me to it
>privately (I know you are on IRC, that tends to often work best for
>me).

Diane's a DD.

thanks and regards
Afif

Bug#879886: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

On November 9, 2017 2:32:56 AM EST, Diane Trout <di...@ghic.org> wrote:
>On Thu, 2017-11-09 at 02:03 -0500, Afif Elghraoui wrote:
>> > - TODO Split private cram headers off into a new libhts-private-dev
>> > package
>> 
>> I'd rather be in favor of restoring the bundled htslib to seqlib as
>> the short term solution. Putting a private package in the archive may
>> exacerbate the problem and is odd nevertheless.
>
>The no convenience copies of libraries is a pretty strong rule of
>Debian, and there are good maintenance reasons for it.

Yes, I understand that, but we don't have good options right now. I don't see 
the maintenance advantages for seqlib as worth requiring a transition for every 
htslib update to make sure it doesn't break--in addition to putting a package 
in the archive and telling users/developers not to install it.

> Although I'm not
>opposed to it I'd like several people to agree that its the best option
>first.
>
>On the plus side overriding it would allow us to drop the patch that is
>making the cram symbols public, on the downside we'd have to remember
>that bugs involving htslib also impact libseqlib.

If this whole situation is primarily seqlib's problem, I think it's only fair 
for it to bear the kludges required for its approach. Otherwise, we have the 
kludge in htslib and the need for a htslib transition with every update, right?

In fact, lofreq never entered Debian because it needs to use samtools as a 
library and we were not going to bundle it [1]. I felt that would be an RC bug.

>
>I think we'd need to use the Built-Using tag? I haven't used that
>before.
>
>On the other hand upstream did suggest that the private-dev library was
>a viable temporary solution. (Though doing that would push htslib into
>NEW).

Well, I think they were saying that if we were going to go so far as to 
misrepresent htslib, we should at the very least make a division and distribute 
htslib proper as such. I read that as saying anything would be better than the 
current situation--not necessarily that they're equally better.

>
>> 
>> And there is another action item--
>> TODO update the htslib package to the latest release.
>
>Very true I did try building 1.6 and there was a problem with
>running tests that I haven't investigated yet.
>

Regards
Afif

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808895

Bug#879886: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

Hi, Diane,

Thanks for working on this.


On November 8, 2017 7:58:49 PM EST, Diane Trout  wrote:
>One of the htslib developers filed a new bug,
>
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881170
>
>asking us to not make their private libraries public. His suggestions
>are fairly similar to whats Charles proposed.
>
>What I'm thinking is:
>
>- TODO Recommit symbols file

+1

>- TODO Split private cram headers off into a new libhts-private-dev
>package

I'd rather be in favor of restoring the bundled htslib to seqlib as the short 
term solution. Putting a private package in the archive may exacerbate the 
problem and is odd nevertheless.

And there is another action item--
TODO update the htslib package to the latest release.

>- WAITING Try to talk htslib & SeqLib developers to agree on a public
>cram api so we can drop the private-dev package.
>
>
> 
>[...]
>
>> 
>> > I was wondering if we should split the cram headers into a
>> > libhts-private-dev so we can at least track what is depending on
>> > the
>> > non-public api.

We would find this out anyway because the packages woukd break until either a 
dependency on such a package had to be added (most likely by our team anyway), 
or the library had to be rebundled.

>> 
>[...]
>
>> 
>> > I did realize that my thought about updating the SOVERSION might be
>> > wrong because I was just looking in the source tree for the removed
>> > functions but I should have been checking the public header files.
>> 
>> Indeed, packages using private functions need to have a tight
>> dependency
>> on the htslib (unless we are very confident that there are regression
>> tests that cover this area of the code).  Packages that are more
>> well-behaved can infer their dependency through the (to be re-added)
>> symbols file.
>
>
>
>So that implies packaging that uses -private-dev that implies they have
>an == dependency on a specific binary version of libhts?
>
>That should probably probably be documented in a README.Debian for the
>private-dev package.
>

Does this imply a transition for each htslib update?

Many thanks and regards
Afif

Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

على الجمعـة  3 تشرين الثاني 2017 ‫17:52، كتب Diane Trout:
> There was also symbols removed between 1.4.1 to 1.5 but upstream didn't
> change their SOVERSION.
> 
> As an aside while I was looking at the missing symbols I found mfprintf
> was still listed in htslib 1.5's cram/mFILE.h, but the implementation
> had been removed from cram/mFILE.c
> 
> Should we be patching the SOVERSION? 
> File a bug upstream to have them update SOVERSION?

This was upstream's advice [1]:

> (When your symbols script comes up with MISSING it would be helpful
> if Debian would start by running "git log -S symbolname" which will
> usually provide an explanation, rather than assuming that something
> terrible has happened.


regards
Afif

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822701#56

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

Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

على الجمعـة 27 تشرين الأول 2017 ‫09:55، كتب Mattia Rizzolo:
> On Fri, Oct 27, 2017 at 12:52:31AM -0400, Afif Elghraoui wrote:
[...]
> 
> What would have been good to prevent the current breakage that has been
> brought to my attention (samtools), what happened is that the newest
> version of samtools picked up a symbol that was not in the original
> libhts2.  Remember that adding symbols is not an ABI break.  Though,
> that requires using a versioned dependency, which in a perfect world
> would be provided (forced?) by a proper htslib packaging.
> 
> 

Would adding a symbols file back to the htslib packaging be an
alternative solution to manually overriding ${shlibs:Depends} in
samtools, bcftools, and python-pysam? The build-depends in these
packages are always versioned appropriately.

regards
Afif

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

Bug#879886: [Debian-med-packaging] Bug#879886: Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

Hi, Mattia and all,

على الخميس 26 تشرين الأول 2017 ‫15:44، كتب Mattia Rizzolo:
> On Thu, Oct 26, 2017 at 12:12:05PM -0700, Diane Trout wrote:
>> libhts2 introduced an ABI change which broke python-pysam, and a new
>> version of python-pysam needed to be released to update to the new ABI.
> 
> FTR, this is what changed between the symbols of the version 1.4.1-5 and
> 1.5-1:
> 
[...]
> 
>> libhts2 probably needs a proper symbols file to make it easier to see
>> when the ABI is changing. https://wiki.debian.org/UsingSymbolsFiles
>>
>> Mattia Rizzolo, also suggests other methods of dealing with managing ABI
>> changes.
> 
> In pysam's case, it is looking for hts_log, if you had properly checked
> the symbols of your package before uploading you should have at least
> tweaked the dh_shlibdeps invocation to force a version, or introduced a
> .symbols file (very recommended for a case like hstlib where the symbols
> seems to be simple).
> 
> But then, the ABI is broken, so just nicest symbols handling is not
> enough for your case, you need
>> Such as bumping soname, changing the package name and use Conflicts, or
>> adding versioned Breaks against broken packages
> 
> 

Please see #822701; specifically:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822701#26
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822701#41 (and
subsequent replies)
and
https://lists.alioth.debian.org/pipermail/debian-med-packaging/2016-January/038827.html
(which is linked from one of the replies to the above)

We've been doing this for every htslib suite release and can confirm
upstream's explanation. Other packages do not get broken. Upstream has
made a soname bump as appropriate for the 1.4 release if I remember
correctly. That's all I can say about this; I don't actually work on the
htslib packaging myself.

regards
Afif

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

Bug#871314: [Debian-med-packaging] Bug#871314: pysam 0.12 depends on libhts2 1.5

[Afif Elghraoui]

Hi, Diane,

On October 26, 2017 1:41:30 PM EDT, "Trout, Diane E."  wrote:
>The new version of pysam 0.12 requires libhts2 1.5.
>
>Unfortunately pysam 0.12 just migrated to testing, and libhts2 was
>blocked from migrating by this bug because it breaks pysam 0.11
>
>
Oh, yeah, that should be closed. There is a similar bug holding up samtools 1.5 
for the same reason that can also be closed. And bcftools 1.5 is held up for 
portability regressions on exotic architectures that nobody has time/interest 
for...

regards
Afif

Bug#878964: ITP: python-easydev -- common utilities to ease the development of Python packages

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Team 
Control: block 878962 by -1
Control: block 878963 by -1

* Package name: python-easydev
  Version : 0.9.35
  Upstream Author : Thomas Cokelaer
* URL : https://easydev-python.readthedocs.io/en/latest/
* License : BSD
  Programming Lang: Python
  Description : common utilities to ease the development of Python packages

 The package easydev provides miscellaneous functions that are often used in
 other Python packages. easydev should help developers in speeding up their
 own developments.

This is a dependency of hinge and python-colormap. It will be maintained by the 
Debian Med team.

Bug#878963: ITP: python-colormap -- ease manipulation of matplotlib colormaps and color codecs

[Afif Elghraoui]

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

* Package name: python-colormap
  Version : 1.0.1
  Upstream Author : Thomas Cokelaer
* URL : https://colormap.readthedocs.io/
* License : BSD
  Programming Lang: Python
  Description : ease manipulation of matplotlib colormaps and color codecs

 The colormap package provides simple utilities to convert colors between RGB,
 HEX, HLS, HUV and a class to easily build colormaps for matplotlib. All
 matplotlib colormaps and some R colormaps are available altogether. The
 plot_colormap method (see below) is handy to quickly pick up a colormaps and
 the test_colormap is useful to see test a new colormap.

This is a dependency for hinge and so will be maintained by Debian Med as well.

Bug#878962: ITP: hinge -- long read genome assembler based on hinging

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Team 

* Package name: hinge
  Version : 0.5
  Upstream Author : Govinda Kamath,
Fei Xia,
Ilan Shomorony,
Thomas Courtade, and
David Tse
* URL : https://github.com/HingeAssembler/HINGE
* License : BSD
  Programming Lang: C++, Python
  Description : long read genome assembler based on hinging

 HINGE is a genome assembler that seeks to achieve optimal repeat resolution
 by distinguishing repeats that can be resolved given the data from those that
 cannot. This is accomplished by adding “hinges” to reads for constructing an
 overlap graph where only unresolvable repeats are merged. As a result, HINGE
 combines the error resilience of overlap-based assemblers with
 repeat-resolution capabilities of de Bruijn graph assemblers.


This will be maintained by the Debian Med team.

Bug#828481: ori: FTBFS with openssl 1.1.0

[Afif Elghraoui]

على الخميس 12 تشرين الأول 2017 ‫17:44، كتب Sebastian Andrzej Siewior:
> Hi,
> 
> this is a remainder about the openssl transition [0]. We really want to
> remove libssl1.0-dev from unstable for Buster. I will raise the severity
> of this bug to serious in a month. Please react before that happens.
> 
> [0] https://bugs.debian.org/871056#55
> 

I've just followed up with upstream, who would actually like to remove
the dependency on openssl altogether.

regards
Afif

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

Bug#868958: [Debian-med-packaging] bcftools FTBFS on 32bit: test failures

[Afif Elghraoui]

على السبت  7 تشرين الأول 2017 ‫05:04، كتب Graham Inggs:
> On 3 October 2017 at 13:52, peter green <plugw...@p10link.net> wrote:
>> Unfortunately while 1.4-3 built successfully on armel, armhf and mipsel
>> 1.5-1 did not.
> 
> I think some patches were missed from the update_1.4.1 branch.
> https://anonscm.debian.org/cgit/debian-med/bcftools.git/log/?h=update_1.4.1
> 

Many thanks, Graham. I was completely unaware of 1.4.1-3 and it was
never committed to master despite being uploaded to the archive. It was
also lost from the changelog for this reason. I'm going to add it back
in. It'd also be extremely helpful if you could forward your patch upstream.

Many thanks and regards
Afif

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

Bug#871083: [Debian-med-packaging] Bug#871083: python-pysam: FTBFS: Test failures

[Afif Elghraoui]

على السبت 30 أيلول 2017 ‫21:52، كتب peter green:
> My understanding is that the new version of python 2.7 removed a module 
> called "_PyFPE" and that C extensions referencing symbols from this module 
> need to be rebuilt. This has been enforced by breaks in the python2.7 
> package. Your package is on said list.
> 
> So for the new python2.7 to migrate to testing the FTBFS in python-pysam 
> needs to be fixed.

Okay, I've just skipped that one failing test and uploaded the new
version in order to move things along.

regards
Afif

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

Bug#871083: [Debian-med-packaging] Bug#871083: python-pysam: FTBFS: Test failures

[Afif Elghraoui]

على السبت 30 أيلول 2017 ‫16:43، كتب Afif Elghraoui:
>  I'll see if I can do it today,

I see Andreas Tille is on top of this. The current issue right now is
this upstream bug we encounter when trying to build the latest upstream
version:

https://github.com/pysam-developers/pysam/issues/542

regards
Afif

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

Bug#871083: [Debian-med-packaging] Bug#871083: python-pysam: FTBFS: Test failures

[Afif Elghraoui]

Hi, Peter,

على السبت 30 أيلول 2017 ‫09:18، كتب peter green:
> Any ETA on fixing this? it is blocking the migration of python2.7 to testing.
> 
> I notice that the package tracker claims that there is a new upstream version 
> available.
> 

The new upstream version is the solution to this problem, but we've been
going back and forth over issues  (fixing one, revealing another) in
updating the package. I'll see if I can do it today, but I don't
understand why this should be blocking python itself. It's not python
that broke this package-- it was updating some of its other dependencies
(htslib/samtools).

regards
Afif

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

Bug#868568: [Adduser-devel] Bug#868568: adduser - deluser command says user has running processes when user has a custom UID assigned

[Afif Elghraoui]

Control: reassign -1 passwd

Hello,

I'm sorry for the delay. As far as Debian Unstable goes, I cannot
reproduce the issue on a clean VM, so it may be limited to Stretch as
you said. In any case, this part:

> root@debian:~# deluser foo
> Removing user `foo' ...
> Warning: group `foo' has no more members.
> userdel: user foo is currently used by process 4892
> /usr/sbin/deluser: `/usr/sbin/userdel foo' returned error code 8. Exiting.

shows that the error is coming from userdel. deluser issued the command
`/usr/bin/userdel foo` and userdel gave you this message. I'm therefore
reassigning this ticket to the passwd package, which is where userdel
comes from. You should hear from its maintainers as a result.

regards
Afif

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

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

[Afif Elghraoui]

Control: reassign -1 udev

Hi, Michael,

على الخميس 15 أيلول 2016 ‫04:20، كتب Michael Biebl:
> 
> Feel free to ping us once --quiet has been fixed and we'll re-add those
> to our maintainer scripts.
> 

I just uploaded adduser with a resolution for #763055. I'm very sorry
for the delay and hope to be much faster in the future.

I think it was a mistake for me to reassign this particular ticket,
since this is about you not using --quiet, but you aren't using --quiet
because it was broken in adduser (the "blocks" relationship you had
added). I think reassigning back, as I did here, will allow its closure
to properly notify the submitters that the problem they encountered is
resolved.

Let me know if there are further issues.

regards
Afif

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

Bug#845925: autopkgtest customize script for vmdebootstrap is unable to resolve httpredir.debian.org

[Afif Elghraoui]

Hello, all,
I was experiencing this problem and was able to get around it by
additionally passing `--no-systemd-networkd --enable-dhcp` to vmdebootstrap.

regards
Afif

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

Bug#860199: incron: NMU/move to collab-maint

[Afif Elghraoui]

Hi, Emmanuel,

Would you mind if I NMU the package to update to the latest upstream, as
well as move the git repository to collab-maint?

Thanks and regards
Afif

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

Bug#823379: Found Maintainer for Elmer

[Afif Elghraoui]

على الثلاثاء  8 آب 2017 ‫16:24، كتب Tobias Frost:
>>
>> This happened over a year ago, let's go ahead with the removal?
> 
> I thinks yes. There was plenty of time to follow up.
> CC'ing Juhani for a last chance.
> (IMHO Otherwise the pacakge can still be ITP at a later time)
> 

The last I heard, he had joined the Debian Science alioth group, but I
didn't follow-up either.

Afif

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

Bug#870637: [Pkg-gridengine-devel] gridengine-client: qstatus does not set default value for SGE_ROOT

[Afif Elghraoui]

Hi, Liang,

Thanks for the report. I suspect there are other tools that expect
SGE_ROOT to be defined globally as well. I'll have to see about whether
they should not expect this or whether these variables should just be
defined globally.

regards
Afif

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

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

[Afif Elghraoui]

Hi, Sergey,

على السبت  8 تـمـوز 2017 ‫07:11، كتب Sergey B Kirpichev:
> On Mon, 20 Feb 2017 22:03:19 -0800 Afif Elghraoui <a...@debian.org> wrote:
>> Anyway, I see the packaging is still in SVN. I'll switch it to Git and
>> prepare a team upload.
> Please ask first other co-maintainers!
> 
> Personally, I'm +1 for packaging in Git.  Unfortunally, Christophe
> rejected this idea in the past.

nlopt is maintained as part of the Debian Science time, and according to
the Debian Science policy, the team has already agreed to use Git as its
VCS [1].

In any case, I have zero time to continue working on this package in the
forseeable future.

regards
Afif

1.
http://debian-science.alioth.debian.org/debian-science-policy.html#idm45916847100528

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

Bug#863929: falcon: FTBFS: Test failures ("Task Node(0-rawreads/job_0001) failed with exit-code=256")

[Afif Elghraoui]

Hello,

على الأربعاء  7 حزيران 2017 ‫08:40، كتب Andreas Tille:
> Hi Adrian,
> 
> On Wed, Jun 07, 2017 at 03:26:49PM +0300, Adrian Bunk wrote:
>>
>>> NMUs are in any case OK for any Debian Med package.  I would have
>>> uploaded as well if I would know the best solution.  So please apply
>>> what you consider best and upload as soon as possible.  Alternatively
>>> send a patch and I'll hurry up.
>>
>> I actually got the same error that Andreas got on i386 also on amd64.
>>
>> It seems you also got the same in the past:
>>   https://lists.debian.org/debian-med/2017/01/msg00085.html
>>
>> In addition to changing the architecture list, my upload
>> (debdiff attached) uses for #863929 the big hammer of no
>> longer running integration-tests.
> 
> Hmmm, we need to discuss this with upstream, thought.  Afif, just let me
> know if you have continuous time constraints or whether you can take
> over from here.
>  

I have unfortunately severe time constraints until the end of Ramadan,
which would be in about 2.5 weeks. I might be able to spare some time on
the weekends, but I don't think this will mean much for falcon.

>> I'll open a new (non-RC) bug to make it visible that this is
>> an issue that should be investigated properly.
> 
> Thanks a lot for your last minute rescue action.  I'll commit your
> changes to Git (however, if you used Git locally feel free to push
> your changes - any DD has commit permissions).
> 

Yes, thank you very much, Adrian!

regards.
Afif

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

Bug#863929: [Debian-med-packaging] Bug#863929: falcon: FTBFS: Test failures ("Task Node(0-rawreads/job_0001) failed with exit-code=256")

[Afif Elghraoui]

على الجمعـة  2 حزيران 2017 ‫15:40، كتب Adrian Bunk:
> On Fri, Jun 02, 2017 at 03:52:51PM +0200, Graham Inggs wrote:
>> According to the reproducible build history [1], this package has FTBFS on
>> i386 for a long time.
>>
>> It also never successfully built on i386 in Ubuntu [2].
>>
>> If there are no objections, I will file a bug requesting removal of the i386
>> binary package.
>> ...
> 
> It always failed on the reproducible builds, but even after the first 
> failures there the build succeeded more than once on i386.
> 
> It does therefore not even make sense to remove the i386 binary since
> it would be expected that any new upload (including after the release) 
> would re-introduce the binary.
> 

It actually does not even make sense to have this package available for
a 32-bit architecture since, for any actual use (de novo genome
assembly), it will require more memory than would be addressable on a
32-bit system. It's not really worth the time and effort to debug that.
I don't know of an alias like !32bit for the Architecture field in
debian/control to exclude that.

regards
Afif

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

Bug#859660: [Debian-med-packaging] Bug#859660: artemis running issue

[Afif Elghraoui]

Hello,

على الأربعاء  5 نيسـان 2017 ‫12:32، كتب Jerome:
> When running artemis package, get this issue :
> 
> $ art
> bash: /usr/bin/art: cannot execute binary file: Exec format error

Hmm, it works for me on jessie. I'll continue to try to reproduce the
problem (maybe this weekend) and report back.

regards
Afif

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

Bug#36019: [Adduser-devel] Bug#36019: Status of Hooks for adduser/deluser?

[Afif Elghraoui]

Hi,

على الإثنين  3 نيسـان 2017 ‫17:28، كتب Patrik Schindler:
> 
> since there’s only infrequent updates on this one, I’d like to ask if there 
> has been any progress on the topic?
> 

No, no updates. My priority for the adduser bugs are those that I've
tagged 'confirmed'. I made patches for some of those, but I haven't
gotten around to setting up a testing environment to verify them and my
spare time has been extremely limited.

regards
Afif

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

Bug#61210: [Adduser-devel] Bug#61210: Comment

[Afif Elghraoui]

Hi,

على الإثنين  3 نيسـان 2017 ‫17:31، كتب Patrik Schindler:
> 
> Perhaps this is a sight duplicate to Bug 36019?
> 

I don't think so. 36019 could be said to be a blocker for this one, though.

Afif

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

Bug#805754: Processed: retitle to RFP: ensembl-tools -- Ensembl tools for genomic data processing

[Afif Elghraoui]

Hi, Andreas,

على السبت  4 آذار 2017 ‫09:54، كتب Andreas Tille:
> Hi Afif,
> 
> you left an empty Git archive
> 
>git://git.debian.org/git/debian-med/ensembl-tools.git
> 
> Do you have any local repository with some preliminary work?  Not that I
> have any specific interest - but I wonder whether there is some stuff
> hanging around which could help once somebody might like to work on
> this.
> 

I did, but VEP (the tool I was interested in) was moved to a separate
upstream project. I am moving soon, so will not have a chance to push my
current work for a while. It involved packaging some other Ensembl APIs
and seems to be difficult to keep up with.

regards
Afif

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

Bug#856671: gridengine: SGE_ARCH not set in /etc/default/gridengine

[Afif Elghraoui]

Package: gridengine
Version: 8.1.9+dfsg-1
Severity: normal
Control: tag -1 + newcomer

The gridengine package does not set the SGE_ARCH variable, which is used in,
for example, qmake as a default architecture resource request. If it isn't
set, you get an error and have to explicitly request an architecture:

qmake(1):
~~~
If no resource request (Grid Engine command line option -l)  is  specified,
qmake  will use the environment variable SGE_ARCH to request the
same architecture as the submit host for task execution.
~~~

The SGE_ARCH variable is best specified in /etc/default/gridengine where
all the other SGE-specific environment variables are set.

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

[Afif Elghraoui]

على الإثنين 20 شباط 2017 ‫08:39، كتب Afif Elghraoui:
> the compiled
> library only works for C++. We need separate packages for the C++ library.

correction:  ^^^ C

Anyway, I see the packaging is still in SVN. I'll switch it to Git and
prepare a team upload.

regards
Afif

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