Bug#946262: dochelp: Fatal error: out of memory

[Mehdi Dogguy]

On 2021-01-27 15:49, Laurent Bonnaud wrote:

On 1/23/21 9:07 PM, Mehdi Dogguy wrote:


Thanks for the bugreport and sorry for not replying earlier!


No problem!


I wasn't able to reproduce this bug.


Thanks for trying!


FWIW, I've just uploaded dochelp 0.1.8 with a couple of bugfixes
(none is related to memory management though). Can you maybe test it
and report back if you still have the issue?


I cannot reproduce the bug any longer.  Difficult to say if it comes
from dochelp's update or other changes on the system.  Anyway, I am
going to close this bug...



Ok, wfm. Thanks for your feedback!

--
Mehdi

Bug#980968: doc-base could suggest dochelp

[Mehdi Dogguy]

Package: doc-base
Version: 0.11
Severity: wishlist

Hi,

I created dochelp some years ago to have simple yet effective tool to
browse doc-base registered documentation installed on one's system.

dochelp doesn't require any webserver or heavy tool. It generates a
static web page which allows searching with some JS. The static web
page is updated by a dpkg trigger (each time a new doc-base file
appears).

Can you please suggest dochelp? (next to dhelp, etc...)

Thanks,

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages doc-base depends on:
pn  libuuid-perl   
ii  libyaml-tiny-perl  1.73-1

doc-base recommends no packages.

Versions of packages doc-base suggests:
ii  yelp  3.38.2-1

Bug#946262: dochelp: Fatal error: out of memory

[Mehdi Dogguy]

On Sat, Jan 23, 2021 at 09:07:13PM +0100, Mehdi Dogguy  wrote:
> I wasn't able to reproduce this bug. Are you able to identify which
> package specifically made dochelp crash? It would help a lot to debug
> it.
>

FWIW, I've just uploaded dochelp 0.1.8 with a couple of bugfixes (none
is related to memory management though). Can you maybe test it and
report back if you still have the issue?

Thanks,

-- 
Mehdi Dogguy

Bug#946262: dochelp: Fatal error: out of memory

[Mehdi Dogguy]

Hi Laurent,

Thanks for the bugreport and sorry for not replying earlier!

On Fri, Dec 06, 2019 at 12:22:14PM +0100, Laurent Bonnaud 
 wrote:
> E: /usr/share/doc-base/scalapack-slug: Field "format" is not allowed in 
> section Document
> E: /usr/share/doc-base/scalapack-pblasqref: Field "format" is not allowed in 
> section Document
> E: /usr/share/doc-base/scalapack-scalapackqref: Field "format" is not allowed 
> in section Document
> E: /usr/share/doc-base/scalapack-faq: Field "format" is not allowed in 
> section Document
> Fatal error: out of memory
> dpkg: error processing package dochelp (--configure):
>  installed dochelp package post-installation script subprocess returned error 
> exit status 2
> Errors were encountered while processing:
>  dochelp
>

I wasn't able to reproduce this bug. Are you able to identify which
package specifically made dochelp crash? It would help a lot to debug
it.

> It can be reproduced with this command:
> 
> # dochelp update
> E: /usr/share/doc-base/scalapack-slug: Field "format" is not allowed in 
> section Document
> E: /usr/share/doc-base/scalapack-pblasqref: Field "format" is not allowed in 
> section Document
> E: /usr/share/doc-base/scalapack-scalapackqref: Field "format" is not allowed 
> in section Document
> E: /usr/share/doc-base/scalapack-faq: Field "format" is not allowed in 
> section Document
> Fatal error: out of memory
> 
> This system has 4GB of RAM and 1GB of swap.
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.4.0-trunk-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages dochelp depends on:
> ii  libc6 2.29-4
> ii  libjs-jquery  3.3.1~dfsg-3
> ii  libpcre3  2:8.39-12+b1
> 
> dochelp recommends no packages.
> 
> dochelp suggests no packages.
> 
> -- no debconf information
> 
> -- 
> Laurent.

-- 
Mehdi Dogguy

Bug#921812: mldonkey-server: Add systemd service file for better security

[Mehdi Dogguy]

Hi Sunil,

On Fri, Feb 08, 2019 at 06:15:44PM -0800, Sunil Mohan Adapa  
wrote:
> It would nice to have a systemd service file for starting/stopping the daemon.
> It would avoid problems like #920466 and improve security due various
> restrictions that systemd can place. Attached is service file that we have
> tested for some simple operations. It lets the log get collected by journald 
> on
> systems running systemd allowing for better log rotation too.
>

I agree it would be a very nice improvement in the packaging. Thanks for 
brining this
up in a bugreport and providing a patch!

I have a doubt about which systemd features to enable by default though. I can 
see
thath Fedora/RedHat enabled really a few, as you can see in [1].

For this reason, I'll ask for advice from Michael (systemd's maintainer). 
Michael,
Sunil here is proposing a .service file for mldonkey-server. I am wondering if 
we
should aim for a simplistic approach as in [1] or if we should enable by default
features proposed by Sunil in his patch (see below). What do you think? What 
would
be your recommendation?

[1] 
https://src.fedoraproject.org/rpms/mldonkey/blob/2a45ff06778cadc4d58435ca1e7187396012c6f1/f/mldonkey.service

Regards,

> [Unit]
> Description=MLDonkey: Multi-protocol, peer-to-peer file sharing server
> After=syslog.target network.target
> ConditionPathExists=/var/lib/mldonkey/downloads.ini
> Documentation=man:mlnet(1) http://mldonkey.sourceforge.net/Main_Page
> 
> [Service]
> ExecStart=/usr/bin/mlnet
> Group=mldonkey
> LockPersonality=yes
> NoNewPrivileges=yes
> PrivateDevices=yes
> PrivateMounts=yes
> PrivateTmp=yes
> PrivateUsers=yes
> ProtectControlGroups=yes
> ProtectHome=yes
> ProtectKernelModules=yes
> ProtectKernelTunables=yes
> ProtectSystem=strict
> ReadWritePaths=/var/lib/mldonkey
> RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
> RestrictRealtime=yes
> StateDirectory=mldonkey
> SystemCallArchitectures=native
> Type=simple
> User=mldonkey
> WorkingDirectory=/var/lib/mldonkey
> 
> [Install]
> WantedBy=multi-user.target

-- 
Mehdi Dogguy

Bug#876966: marked as pending in ben

[Mehdi Dogguy]

On 2021-01-05 22:07, Christoph Berg wrote:

Re: Mehdi Dogguy

Bug #876966 in ben reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit


I pulled scripts.js manually and change works nicely. Thanks!



Thanks a lot for checking, Christoph!

Happy new year,

--
Mehdi

Bug#910485: Confirm issue with libpsm2-2/11.2.68-1

[Mehdi Dogguy]

Sure, but it is still an improvement over the current situation and is simple 
enough to minimize its impact. Of course, it should be considered as a 
wrkaround, until upstream releases a fixed version.


Le 29 octobre 2018 19:41:06 GMT+01:00, Brian Smith 
 a écrit :
>Hi Mehdi,
>
>
>On Mon, Oct 29, 2018 at 4:48 AM Mehdi Dogguy  wrote:
>>
>> Sorry for not replying sooner.
>>
>> On 2018-10-20 17:54, Brian Smith wrote:
>> > The change is in psm2_hal.c. It is a brand new file. Reference the
>> > initialization loop at line 246.
>> >
>>
>> Indeed. The solution described in the github issue looks very fine.
>> Why not uploading it in Debian? It will solve a real issue for users
>> (and reverse dependencies) while giving upstream more time to
>> investigate it.
>>
>> --
>> Mehdi
>
>Thank you for looking it over. I'm still working with upstream to get
>an approved patch. The proposed patch corrects the symptom that
>resulted in this issue, but I can't guarantee it won't cause some
>other aberrant behavior.

-- 
Mehdi

Bug#910485: Confirm issue with libpsm2-2/11.2.68-1

[Mehdi Dogguy]

Sorry for not replying sooner.

On 2018-10-20 17:54, Brian Smith wrote:

The change is in psm2_hal.c. It is a brand new file. Reference the
initialization loop at line 246.



Indeed. The solution described in the github issue looks very fine.
Why not uploading it in Debian? It will solve a real issue for users
(and reverse dependencies) while giving upstream more time to
investigate it.

--
Mehdi

Bug#910485: Confirm issue with libpsm2-2/11.2.68-1

[Mehdi Dogguy]

On 2018-10-19 19:53, Brian Smith wrote:

The problem occurs when the OFI psm2 provider invokes psm2_init() when
there are no hfi1 devices present on the system. The call chain
eventually invokes hfi1_wait_for_device() with a timeout of 0. That is
interpreted as 15000ms.



Actually, that part of the code didn't change at all. I was able to
reproduce the issue, but I am not actually sure yet from where the
regression is coming.

--
Mehdi

Bug#910485: Confirm issue with libpsm2-2/11.2.68-1

[Mehdi Dogguy]

Hi Jonas,

On 2018-10-15 19:54, Lippuner, Jonas wrote:

I'm having the same issue with libpsm2-2 version 11.2.68-1. Downgrading
to 10.3.58-2 fixes it for me.


Can you please explain how you experienced the bug? I've understood 
Drew's

case, but maybe yours is slightly different.

--
Mehdi

Bug#908203: opam: Should not depend on aspcud any more

[Mehdi Dogguy]

On 2018-09-09 10:44, Ralf Jung wrote:

Hi Mehdi,


On 2018-09-07 12:42, Ralf Jung wrote:

Package: opam
Version: 2.0.0-2
Severity: normal

Dear Maintainer,

Quoting from https://opam.ocaml.org/doc/2.0/External_solvers.html:

As of 2.0.0, opam comes with a CUDF solver built-in by default, so 
unless you
have specifically compiled without it, you shouldn't have to be 
worried about

installing an external solver.


So, aspcud should at best be a recommendation, not a dependency.  
Likely, it
should just be a suggestions; the internal solver is used by default 
even when

aspcud is installed.



If I am not mistaken, the built-in solver is not enabled in the Debian 
package
because we are missing ocaml-mccs to make it work. So, for now, the 
dependency

is still needed.


Oh... that's a bummer, because using the new built-in solver is one of 
the
biggest reasons to update to opam 2 for me. :/  aspcud keeps computing 
really

strange solutions in some cases I frequently run into.



Indeed.

This also means Debian users will not get the default and 
upstream-intended
behavior of opam, which will be very confusing in particular for 
bugreports.




We agree. Our intent is to package ocaml-mccs in time to include it in 
Buster and
have a full featured OPAM 2 in Debian. Unfortunately, we did not 
anticpated ocaml-mccs's

packaging. But hopefully it is only a matter of time.


 Is there an issue that tracks fixing this?


Not yet, (I didn't see an RFP or ITP bugreport about this) [1]. Do you 
mind filing
an RFP bug please for ocaml-mccs? (and add 
debian-ocaml-maint%40lists.debian.org in

the X-debbugs-CC).


[1] https://www.debian.org/devel/wnpp/
--
Mehdi

Bug#908203: opam: Should not depend on aspcud any more

[Mehdi Dogguy]

Hi Ralf,

On 2018-09-07 12:42, Ralf Jung wrote:

Package: opam
Version: 2.0.0-2
Severity: normal

Dear Maintainer,

Quoting from https://opam.ocaml.org/doc/2.0/External_solvers.html:

As of 2.0.0, opam comes with a CUDF solver built-in by default, so 
unless you
have specifically compiled without it, you shouldn't have to be 
worried about

installing an external solver.


So, aspcud should at best be a recommendation, not a dependency.  
Likely, it
should just be a suggestions; the internal solver is used by default 
even when

aspcud is installed.



If I am not mistaken, the built-in solver is not enabled in the Debian 
package
because we are missing ocaml-mccs to make it work. So, for now, the 
dependency

is still needed.

Regards,

--
Mehdi

Bug#907946: RFH: frama-c -- Platform dedicated to the analysis of source code written in C

[Mehdi Dogguy]

Package: wnpp
Severity: normal

Hi all,

Frama-c is a great tool to perform static analysis on source code 
written in C
(... write your own analysis plugins and many other neat features). But 
it
requires time to maintain it properly. I do not have that time anymore 
and I

do not use Frama-c any longer.

Time permitting, I will continue to upload new releases and fix 
outstanding bugs
but certainly not in sync with frama-c's release cycle. I am willing to 
mentor
people familiar with OCaml and willing to maintain Frama-c in the 
future.


--
Mehdi

Bug#907042: opam 1.2.0 is deprecated (jessie)

[Mehdi Dogguy]

Hi nico,

On 2018-08-23 16:53, Nicolas Braud-Santoni wrote:

Hi Mehdi,

On Thu, Aug 23, 2018 at 03:00:22PM +0200, Mehdi Dogguy wrote:

> [...]
> It makes opam unusable for jessie users: already initialised ones can't
> install new compilers nor update packages, and with a fresh install opam
> is almost unusable (e.g. [3]).

Unfortunately, we won't be able to upgrade Opam to 1.2.2 in Debian 
stable.


fwiw, I meant "oldstable" above.

I can ask for its removal, or document in this bugreport how to point 
their

installation to a frozen working mirror?


Doesn't the release policy allow shipping a new upstream version to 
*-pu, if
there is no other way to get the bug resolved (and after consulting the 
release

team) ?  Or is the issue that there won't be new point releases ?



I am not sure what the Release Team would accept at this point (Jessie 
is already
EOL'ed). So, a sloppy-backport should be enough for oldstable users. 
They can
upgrade to stable if necessary. Once, 2.0 will be ready in Buster, 
Stretch users

can use from backports.

--
Mehdi

Bug#907042: opam 1.2.0 is deprecated (jessie)

[Mehdi Dogguy]

On 2018-08-23 13:36, rjbou wrote:

Package: opam
Version: 1.2.0-1+deb8u1
Severity: grave
Justification: renders package unusable
Tags: jessie

Dear Maintainer,

On jessie, opam 1.2.0 is packaged but it is officially deprecated since
a year [1][2].

It makes opam unusable for jessie users: already initialised ones can't
install new compilers nor update packages, and with a fresh install 
opam

is almost unusable (e.g. [3]).

The solution is to upgrade the opam package to 1.2.2.



Unfortunately, we won't be able to upgrade Opam to 1.2.2 in Debian 
stable.
I can ask for its removal, or document in this bugreport how to point 
their

installation to a frozen working mirror?

In the meantime, I'll work on a {sloppy-,}backport of 1.2.2.

--
Mehdi

Bug#899238: RFP: ppx-tools-versioned -- Tools for authors of ppx rewriters

[Mehdi Dogguy]

Indeed :-)

Le 22 juin 2018 05:00:35 GMT+02:00, Andy Li  a écrit :
>On Fri, Jun 22, 2018 at 5:01 AM, Mehdi Dogguy  wrote:
>> Excellent work! I've reviewed it and it looks fine. I'll upload it
>shortly.
>> Would you mind retitling thing bug to an "ITP: ..." and setting
>yourself
>> as its owner?
>
>Thanks, Mehdi.
>I've already updated the title and the owner before working on it as
>seen in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899238
>It is just I'm replying the message in my email client, so the subject
>line is still using the old title :)
>
>Best,
>Andy

-- 
Mehdi

Bug#899238: RFP: ppx-tools-versioned -- Tools for authors of ppx rewriters

[Mehdi Dogguy]

Hi Andy,

On 2018-06-20 11:52, Andy Li wrote:


I've created an initial version of the package in salsa:
https://salsa.debian.org/ocaml-team/ppx-tools-versioned
Tested building it with sbuild (and adt-run) for both amd64 and mips.
Would you review it?



Excellent work! I've reviewed it and it looks fine. I'll upload it 
shortly.

Would you mind retitling thing bug to an "ITP: ..." and setting yourself
as its owner?

Cheers,

--
Mehdi

Bug#891395: marked as done (libfabric1: improperly packaged library support files)

[Mehdi Dogguy]

Control: reopen -1

Hi Roland,

If I am not mistaken, your last upload moves files across binary
packages but doesn't add necessary Breaks/Replaces. In the current
state, upgrades are broken because older libfabric1 and newer
libfabric-dev are not co-installable.

Regards,

--
Mehdi

Bug#901132: Enable support for PSM2

[Mehdi Dogguy]

Source: openmpi
Version: 3.1.0-6
Severity: normal

Hi,

PSM2 was accepted in Debian a few weeks ago. It would be very nice to
see its support enabled in OpenMPI.

Cheers,

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#900018: FTBFS with latest cmdliner

[Mehdi Dogguy]

Hi Andy,

On 2018-05-25 08:40, Andy Li wrote:

I've a patch:
https://github.com/ocaml/opam/compare/1.2.2...andyli:1.2.2-fix.patch
It's based on the discussion with upstream at
https://discuss.ocaml.org/t/the-forever-beta-issue/1779/6



In fact, the patch introduces a bug and makes the build fail later in
the process (can't generate manpages and test-suite doesn't succeed).

Do you confirm this on your side as well?

--
Mehdi

Bug#900674: RFP: odoc -- documentation generator for OCaml

[Mehdi Dogguy]

Package: wnpp
Severity: wishlist

* Package name: odoc
  Version : 1.2.0
  Upstream Author : Thomas Refis and al.
* URL : https://github.com/ocaml/odoc
* License : ISC
  Programming Lang: OCaml
  Description : documentation generator for OCaml

odoc is a documentation generator for OCaml. It reads doc comments,
delimited with (** ... *), and outputs HTML.

odoc's main advantage over ocamldoc is an accurate cross-referencer,
which handles the complexity of the OCaml module system. odoc also
offers a good opportunity to improve HTML output compared to ocamldoc.

Furthermore, odoc can be used by jbuilder/dune to generate
documentation of OCaml projects using jbuilder/dune as a build-system.

If you want to maintain odoc, please consider joining the OCaml team:
https://wiki.debian.org/Teams/OCamlTaskForce/

Bug#900018: FTBFS with latest cmdliner

[Mehdi Dogguy]

Hi Andy,

On 2018-05-25 08:40, Andy Li wrote:

I've a patch:
https://github.com/ocaml/opam/compare/1.2.2...andyli:1.2.2-fix.patch


That's great!

FWIW, I've opened this bug report so that Opam doesn't migrate to
testing before being fixed or updated to a newer version. I have
the feeling that OPAM team is not willing to support OPAM 1.2.2
for a long time. So it doesn't make sense, at least for me, to
include it in Buster.

Yesterday, I've uploaded opam-file-format to NEW. As soon as it gets
accepted, I'll upload latest version of OPAM to Debian/Sid.


It's based on the discussion with upstream at
https://discuss.ocaml.org/t/the-forever-beta-issue/1779/6



Thanks for the pointer.

Cheers,

--
Mehdi

Bug#900018: FTBFS with latest cmdliner

[Mehdi Dogguy]

Package: opam
Version: 1.2.2-6+b1
Severity: serious

opam fails to build from source using latest cmdliner which was uploaded
to Debian/Sid a few days ago:

File "client/opamArg.ml", line 384, characters 25-29:
Error: This expression has type
 ?docv:string ->
 (string -> ('a, [ `Msg of string ]) result) * 'a printer ->
 'a converter
   but an expression was expected of type
 'b converter = 'b parser * 'b printer
../OCamlMakefile:1076: recipe for target 'client/opamArg.cmo' failed

Full build log can be found here:

   
https://buildd.debian.org/status/fetch.php?pkg=opam=armel=1.2.2-6%2Bb3=1526941860=0

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages opam depends on:
ii  build-essential  12.4
ii  curl 7.58.0-2
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.27-3
ii  opam-docs1.2.2-6
ii  tar  1.30+dfsg-2
ii  unzip6.0-21
ii  wget 1.19.5-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages opam recommends:
ii  aspcud 1:1.9.4-1
pn  darcs  
ii  git1:2.17.0-1
pn  mercurial  
pn  ocaml  
ii  rsync  3.1.2-2.1

opam suggests no packages.

-- no debconf information

Bug#876478: ben tracker --global-conf ignores settings

[Mehdi Dogguy]

Hi,

On 2018-05-21 18:43, Sebastiaan Couwenberg wrote:


Do you still have to for the documentation update?



I've published new instructions on Ben's website (which
is generated from Ben's git repository). You can read
them here: https://ben.debian.net/#_tracker

Basically, it is:
$ ocamlbuild -pkg ben foo.cmx
$ ocamlopt -shared -o foo.cmxs _build/foo.cmx

In short: Do not use ocamlbuild to generate the .cmxs
file.

--
Mehdi

Bug#869114: status of the topkg package

[Mehdi Dogguy]

Hi,

On 2018-05-21 08:49, Andy Li wrote:

Hi Hendrik,

What is the status of the topkg package?
I want to update jsonm, which now depends on topkg.



FWIW, I updated jsonm today using a custom debian/rules file (the
famous debian/rules file used for pretty much all Daniel's software
packaged in Debian).

Regards,

--
Mehdi

Bug#899238: RFP: ppx-tools-versioned -- Tools for authors of ppx rewriters

[Mehdi Dogguy]

Package: wnpp
Severity: wishlist

* Package name: ppx-tools-versioned
  Version : 5.1
  Upstream Author : Alain Frisch and al.
* URL : https://github.com/ocaml-ppx/ppx_tools_versioned
* License : MIT
  Programming Lang: OCaml
  Description : Tools for authors of ppx rewriters

This library is a variant of ppx-tools where all tools are versioned.
It is needed to build latest versions of tyxml.

Bug#899237: RFP: markup.ml -- Error-recovering streaming HTML5 and XML parsers

[Mehdi Dogguy]

Package: wnpp
Severity: wishlist

* Package name: markup.ml
  Version : 0.7.6
  Upstream Author : Anton Bachin
* URL : https://github.com/aantron/markup.ml
* License : BSD-2
  Programming Lang: OCaml
  Description : Error-recovering streaming HTML5 and XML parsers

Markup.ml is a pair of parsers implementing the HTML5 and XML
specifications, including error recovery. Usage is simple, because
each parser is a function from byte streams to parsing signal streams.

This software is needed as a new build dependency for tyxml.

Bug#876478: ben tracker --global-conf ignores settings

[Mehdi Dogguy]

On 2018-05-14 18:46, Sebastiaan Couwenberg wrote:

On 05/14/2018 08:26 AM, Mehdi Dogguy wrote:

On 2018-05-14 08:01, Sebastiaan Couwenberg wrote:
Unfortunately that doesn't apply cleanly on top of 0.7.4 for stretch. 
If

you can provide a rebased commit for 0.7.4 I'm willing to test that.



No problem. Here it is (attached). Thanks for your tests!


Thanks for the patch, it doesn't seem to work as expected, though.

`ben tracker` downloads the Packages & Sources files again even when
`ben download` downloaded them just before. It also uses the current
working directory for the downloaded files instead of the cache-dir 
from

the global.conf.

It looks like this is caused by the custom template that was built with
the old ben, because switching the template to debianrt in global.conf
results in the expected behaviour.



Indeed. I didn't explain fully how to apply the patch. My apologies.

The only effect of my second patch is to build templates differently to
avoid linking and include all Ben's library. So in order to have this
bug fixed, templates must be recompiled.


Rebuilding the template fails when executed from the root of the git
directory:

 $ ocamlbuild -pkg ben debiangis.cmxs
 + /usr/bin/ocamlopt unix.cmxa -I /usr/lib/ocaml/ocamlbuild
/usr/lib/ocaml/ocamlbuild/ocamlbuildlib.cmxa -I /usr/lib/ocaml -I
/usr/lib/ocaml/ben -I /usr/lib/ocaml/bytes -I /usr/lib/ocaml/ocamlgraph
-I /usr/lib/ocaml/pcre -I /usr/lib/ocaml/tyxml -I /usr/lib/ocaml/uutf
/usr/lib/ocaml/unix.cmxa /usr/lib/ocaml/pcre/pcre.cmxa
/usr/lib/ocaml/ocamlgraph/graph.cmxa /usr/lib/ocaml/str.cmxa
/usr/lib/ocaml/uutf/uutf.cmxa /usr/lib/ocaml/tyxml/tyxml.cmxa
/usr/lib/ocaml/ben/benl.cmxa myocamlbuild.ml
/usr/lib/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
 File "myocamlbuild.ml", line 1:
 Error: Files /usr/lib/ocaml/unix.cmxa and /usr/lib/ocaml/unix.cmxa
both define a module named Unix



It is true that the fix needs a documentation update to specify how
templates should be built. I'll send you one very soon.

If you have an already built plugin, you may use the 
/usr/lib/ocaml/expunge

tool to hide/remove non-necessary modules (that you can list using
ocamlobjinfo). But, in any case, I'll provide a new procedure to build
custom plugins.

Regards,

--
Mehdi

Bug#876478: ben tracker --global-conf ignores settings

[Mehdi Dogguy]

On 2018-05-14 08:01, Sebastiaan Couwenberg wrote:
Unfortunately that doesn't apply cleanly on top of 0.7.4 for stretch. 
If

you can provide a rebased commit for 0.7.4 I'm willing to test that.



No problem. Here it is (attached). Thanks for your tests!

Kind Regards,

--
Mehdi--- a/_tags
+++ b/_tags
@@ -2,4 +2,4 @@
 <**/*.ml*>: annot
 : for-pack(Benlib)
 : use_libbenl
-<**/*.{byte,native}>: use_libbenl
+: use_libbenl
--- a/myocamlbuild.ml
+++ b/myocamlbuild.ml
@@ -96,6 +96,18 @@ let () =
 flag ["ocaml"; "compile"; "native"] (S[A"-inline"; A"1000"]);
 flag ["ocaml"; "link"; "native"] (S[A"-inline"; A"1000"]);
 
+(* Templates *)
+rule "template: cmx -> cmxs"
+  ~prod:"%.cmxs"
+  ~dep:"%.cmx"
+  ~insert:`top
+  ~doc:"This rule allows to build a .cmxs from a .cmx, without 
including all its dependencies." begin
+fun env _ ->
+  let cmx = env "%.cmx" in
+  let cmxs = env "%.cmxs" in
+  Cmd(S[!Options.ocamlopt; A "-shared"; A "-I"; A "templates"; A 
cmx; A "-o"; A cmxs])
+  end;
+
 (* why isn't this done by default? *)
 flag ["library"; "link"; "thread"] (A"-thread");
 

Bug#876478: ben tracker --global-conf ignores settings

[Mehdi Dogguy]

On 2018-05-13 21:10, Sebastiaan Couwenberg wrote:


I've applied that commit on top of ben (0.7.4) from stretch, and it
resolves this issue. The Packages & Sources files are no longer
downloaded again when `ben tracker ...` is executed, and the various
settings from the global.conf files are used again.



FWIW, I've got a better fix:

https://salsa.debian.org/debian/ben/commit/c298da34ec0f4ebc0e68e51a220c2fd9b04fa6fd

It fixes the issue at its root, and doesn't only workaround one specific 
case.


--
Mehdi

Bug#876478: ben tracker --global-conf ignores settings

[Mehdi Dogguy]

On 2018-05-13 21:10, Sebastiaan Couwenberg wrote:

On 05/13/2018 08:32 PM, Mehdi Dogguy wrote:

On 2018-05-13 15:44, Sebastiaan Couwenberg wrote:
Those are the files in the current working directory, and may be from 
a

different distribution.

All the global.conf files use a separate cache-dir but this setting 
has

no effect any more.

The same goes for the list of architectures and ignored ones, these
settings are no longer used. It looks like the hardcoded defaults are
used instead.


Indeed. I think I found the culprit. Can you test this commit?

https://salsa.debian.org/debian/ben/commit/aba1f9a8e567502da18c11b8b89dc45f9eed4c19


I've applied that commit on top of ben (0.7.4) from stretch, and it
resolves this issue. The Packages & Sources files are no longer
downloaded again when `ben tracker ...` is executed, and the various
settings from the global.conf files are used again.



Great.


Will this fix find its way into a stretch-pu?



I'll try to submit it. Not sure if Release Managers would accept it.

Kind Regards,

--
Mehdi

Bug#876478: ben tracker --global-conf ignores settings

[Mehdi Dogguy]

On 2018-05-13 15:44, Sebastiaan Couwenberg wrote:

Those are the files in the current working directory, and may be from a
different distribution.

All the global.conf files use a separate cache-dir but this setting has
no effect any more.

The same goes for the list of architectures and ignored ones, these
settings are no longer used. It looks like the hardcoded defaults are
used instead.



Indeed. I think I found the culprit. Can you test this commit?

https://salsa.debian.org/debian/ben/commit/aba1f9a8e567502da18c11b8b89dc45f9eed4c19

Kind Regards,

--
Mehdi

Bug#876478: ben tracker --global-conf ignores settings

[Mehdi Dogguy]

Hi Sebastiaan,

On 2018-05-13 14:13, Sebastiaan Couwenberg wrote:

On 05/13/2018 01:59 PM, Mehdi Dogguy wrote:

On 2018-05-13 13:51, Sebastiaan Couwenberg wrote:

On 05/13/2018 01:25 PM, Mehdi Dogguy wrote:

On 2017-09-22 18:37, Bas Couwenberg wrote:

Package: ben
Version: 0.7.4+b4
Severity: important

Dear Maintainer,

Since the upgrade to stretch my ben setup no longer works as 
before.


The `ben tracker --global-conf /global.conf` commands don't 
use

the cache file as configured in the global.conf file, and instead
download the Sources & Packages files again (which were downloaded
before
using `ben download -c /global.conf`).

The downloaded files also use the current working directory instead 
of

the cache-dir configured in global.conf



Do you have "use-cache = true;" in your global.conf file?


Yes.



Can you please share your setup so that I can reproduce it and debug 
it?

(scripts, configuration files)


https://linuxminded.nl/tmp/ben.tar.gz

That contains my entire ben directory.



Great, thanks!

I noticed you had the following line at the beginning of your 
ben-tracker-*.sh

scripts:

  rm -f ben.cache Packages_* Sources

Since those scripts are executed after ben-download-*.sh scripts, it may 
explain

the behaviour your are experiencing.

Regards,

--
Mehdi

Bug#876478: ben tracker --global-conf ignores settings

[Mehdi Dogguy]

On 2018-05-13 13:51, Sebastiaan Couwenberg wrote:

On 05/13/2018 01:25 PM, Mehdi Dogguy wrote:

On 2017-09-22 18:37, Bas Couwenberg wrote:

Package: ben
Version: 0.7.4+b4
Severity: important

Dear Maintainer,

Since the upgrade to stretch my ben setup no longer works as before.

The `ben tracker --global-conf /global.conf` commands don't use
the cache file as configured in the global.conf file, and instead
download the Sources & Packages files again (which were downloaded 
before

using `ben download -c /global.conf`).

The downloaded files also use the current working directory instead 
of

the cache-dir configured in global.conf



Do you have "use-cache = true;" in your global.conf file?


Yes.



Can you please share your setup so that I can reproduce it and debug it?
(scripts, configuration files)


Kind Regards,

Bas


--
Mehdi

Bug#895166: ben: move out of asciidoc

[Mehdi Dogguy]

Hi,

On 2018-04-08 03:41, Joseph Herlant wrote:

Package: ben
Version: 0.7.7
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the 
different

packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

Could you have your package migrated to an alternative system please?



I've done the necessary changes to use asciidoctor instead of asciidoc 
and

pushed my changes to Ben's Git repository. This bug will be closed with
the next upload.

Regards,

--
Mehdi

Bug#876478: ben tracker --global-conf ignores settings

[Mehdi Dogguy]

Hi,

On 2017-09-22 18:37, Bas Couwenberg wrote:

Package: ben
Version: 0.7.4+b4
Severity: important

Dear Maintainer,

Since the upgrade to stretch my ben setup no longer works as before.

The `ben tracker --global-conf /global.conf` commands don't use
the cache file as configured in the global.conf file, and instead
download the Sources & Packages files again (which were downloaded 
before

using `ben download -c /global.conf`).

The downloaded files also use the current working directory instead of
the cache-dir configured in global.conf



Do you have "use-cache = true;" in your global.conf file?

--
Mehdi

Bug#886925: libpsm-infinipath1: leaves alternatives after purge: /etc/alternatives/libpsm_infinipath.so.1 -> /usr/lib/libpsm1/libpsm_infinipath.so.1.16

[Mehdi Dogguy]

Hi Andreas,

Thank for you for the bugreport and throughout explanation!

On 11/01/2018 13:21, Andreas Beckmann wrote:
> Package: libpsm-infinipath1
> Version: 3.3+20.604758e7-4
> Severity: important
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package left unowned files on
> the system after purge, which is a violation of policy 6.8:
> 
> https://www.debian.org/doc/debian-policy/#details-of-removal-and-or-configuration-purging
> 
> The leftover files are actually alternatives that were installed by the
> package but have not been properly removed.
> 
> While there is ongoing discussion how to remove alternatives correctly
> (see https://bugs.debian.org/71621 for details) the following strategy
> should work for regular cases:
> * 'postinst configure' always installs the alternative
> * 'prerm remove' removes the alternative
> * 'postrm remove' and 'postrm disappear' remove the alternative

Unfortunately, the latter raises the following lintian warning:
https://lintian.debian.org/tags/maintainer-script-should-not-use-update-alternatives-remove.html

Are you positive this is needed? If so, is it a bug in lintian?

> In all other cases a maintainer script is invoked (e.g. upgrade,
> deconfigure) the alternatives are not modified to preserve user
> configuration.
> Removing the alternative in 'prerm remove' avoids having a dangling link
> once the actual file gets removed, but 'prerm remove' is not called in
> all cases (e.g. unpacked but not configured packages or disappearing
> packages) so the postrm must remove the alternative again
> (update-alternatives gracefully handles removal of non-existing
> alternatives).
> 

Regards,

-- 
Mehdi

Bug#885759: slurmd default PID file disagrees with systemd service

[Mehdi Dogguy]

On 12/01/2018 21:45, Hattne, Johan wrote:
> 
>> On Jan 12, 2018, at 15:00, Mehdi Dogguy <me...@dogguy.org> wrote:
>> 
>> I agree. My patch would only help others to not fall into the trap of
>> using slurm's default pid paths. A more suitable mid-term goal would be to
>> use /var/run as a state dir, just like upstream. I'll leave this bugreport
>> open (and retitle it accordingly) to remind us about what's remaining to
>> do.
> 
> OK, thanks!  From memory, I think the directory where the PID file is written
> is not statedir as configured through the autotools but rather something
> hardcoded in the source.
> 

Yes, I am using this patch:

https://anonscm.debian.org/git/collab-maint/slurm-llnl.git/commit/?id=d18690bbf1b8aa8b9d57b9e755841fdf67cf6aaa

> And just to clarify, by default Debian’s slurmd already writes its PID-file
> there, it’s just that startup-scripts expect the location to be customized
> (as is done through e.g. the default Debian configuration file).  However, I
> at least some slurm installations cannot use the Debian configuration file
> everywhere.
> 

Sure.

-- 
Mehdi

Bug#885759: slurmd default PID file disagrees with systemd service

[Mehdi Dogguy]

Control: retitle 885759 Use /var/run as a statedir, and not /var/run/slurm-llnl

On 12/01/2018 19:39, Hattne, Johan wrote:
> 
> I’m not sure providing a consistent value in the default configuration file
> would be appropriate.  If one sets SlurmPidFile in slurm.conf, it will apply
> to all the members of the cluster, because slurm.conf (by default) has to be
> identical on all the nodes.  This is fine if all the nodes are identically
> configured.
> 

Indeed, but this works fine if your cluster runs the same OS.

> However, we have a somewhat heterogenous cluster, where some nodes are not
> running Debian, and their startup scripts consequently look for the PID-file
> in /var/run (the default in the slurm code).  If we set SlurmPidFile to
> /var/run/slurm-llnl/slurmd.pid we run into the same issue there.
> 

Indeed. That's the case where things work less nicely. :-) While not ideal, a
simple "mkdir" and an update to the configuration file would solve this
incoherence.

> I suppose patching slurm to write its PID file to
> /var/run/slurm-llns/slurmd.pid in conjunction with a consistent default
> configuration file would work as well, but that’s a bit more work (and the
> Debian slurm will diverge a tad from upstream).
> 

I agree. My patch would only help others to not fall into the trap of using
slurm's default pid paths. A more suitable mid-term goal would be to use
/var/run as a state dir, just like upstream. I'll leave this bugreport open
(and retitle it accordingly) to remind us about what's remaining to do.

Before doing so, I'd like to hear from my co-maintainer about the reasons of
why we are using /var/run/slurm-llnl instead of /var/run in case I've missed
something.

Regards,

-- 
Mehdi

Bug#885759: slurmd default PID file disagrees with systemd service

[Mehdi Dogguy]

Hello,

On Fri, Dec 29, 2017 at 05:58:10PM +, "Hattne, Johan" 
<hatt...@janelia.hhmi.org> wrote:
> Package: slurmd
> Version: 16.05.9-1+deb9u1
>
> By default, slurmd writes its PID file to /var/run/slurmd.pid, but
> the systemd service expects it to be at
> /var/run/slurm-llnl/slurmd.pid.  As a result, "systemctl start
> slurmd" hangs unless slurm.conf defines
> SlurmdPidFile=/var/run/slurm-llnl/slurmd.pid.  This could be
> synchronized by either patching the slurmd code or modifying the
> service file; I’m guessing the latter is more appropriate.
> --- /lib/systemd/system/slurmd.service2017-11-05 05:26:27.0 
> -0500
> +++ /etc/systemd/system/slurmd.service2017-12-28 17:24:40.708918382 
> -0500
> @@ -8,7 +8,7 @@
>  Type=forking
>  EnvironmentFile=/etc/default/slurmd
>  ExecStart=/usr/sbin/slurmd $SLURMD_OPTIONS
> -PIDFile=/var/run/slurm-llnl/slurmd.pid
> +PIDFile=/var/run/slurmd.pid
>  
>  [Install]
>  WantedBy=multi-user.target
>
> I assume the same applies to the other slurm daemons.  This is on
> Debian 9.3.

Thank you for the bugreport and sorry for not getting back to you sooner.
The fact that slurm's default do not match values from its debian package
is indeed an issue and may lead to situations like the one you are
describing. Though it is not necessary to change the .service file. You
can specify SlurmctldPidFile, SlurmdPidFile or PidFile in the appropriate
configuration files for (respectively) slurmctld, slurmd and slurmdbd.

I am not going to revert changes on the run directory in the debian
packaging for now (as I guess my co-maintainer had good reasons to override
them), but I'll change debian's provided slurm's defaults to be coherent
with the reste of the package.

Regards,

-- 
Mehdi Dogguy

Bug#797535: vmpk status

[Mehdi Dogguy]

Hi Ross,

It is great to hear that pkg-multimedia is willing to take care of this
package. Did you make any progress on this package?

AFAIK, current version is broken and doesn't work anymore. An update to
the latest upstream version is very much needed.

Regards,

--
Mehdi

Bug#886387: closed by Mehdi Dogguy <me...@debian.org> (Bug#886387: fixed in mstflint 4.8.0-2)

[Mehdi Dogguy]

reopen 886387
found 886387 linux/4.14.7-1~bpo9+1
kthxbye

On Fri, Jan 05, 2018 at 11:51:07AM +, Debian Bug Tracking System 
<ow...@bugs.debian.org> wrote:
>  mstflint (4.8.0-2) unstable; urgency=medium
>  .
>* Make the build reproducible (Closes: #886387). Thanks to Chris Lamb
>  for the patch.
>  - add 0012-Reproducible-build.patch

I made a typo in the changelog and closed the wrong bug. Sorry for that. I am
opening it again.

Regards,

-- 
Mehdi Dogguy

Bug#871912: frama-c FTBFS on ppc64el/s390x/mips*: configure: error: native dynlink does not work.

[Mehdi Dogguy]

Hi,

Thank you for this report.

On 12/08/2017 09:33, Adrian Bunk wrote:
> configure: ***
> configure: * CONFIGURE TOOLS AND LIBRARIES USED BY SOME PLUG-INS *
> configure: ***
> Ocamlfind -> using +lablgtk2.(/usr/lib/ocaml/lablgtk2,/usr/lib/ocaml/lablgtk2)
> checking for /usr/lib/ocaml/lablgtk2/lablgtksourceview2.cma... yes
> checking for /usr/lib/ocaml/lablgtk2/lablgnomecanvas.cma... yes
> checking for /usr/lib/ocaml/lablgtk2/lablgtk.cma... yes
> checking for dot... yes
> configure: error: native dynlink does not work.
> debian/rules:13: recipe for target 'override_dh_auto_configure' failed
> make[1]: *** [override_dh_auto_configure] Error 2
> 

For reference: After seeing this build failure after my upload, I have sent
a mail to upstream asking whether bytecode architectures are still supported.
I didn't want to patch Frama-C to make it build again there is there is no
will from upstream to support those architectures (It is trivial to fix but
might a useless effort). I am still waiting for their reply.

-- 
Mehdi

Bug#861283: unblock: slurm-llnl/16.05.9-1

[Mehdi Dogguy]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Slurm 16.05.9-1 has been uploaded to Unstable a while ago and is a bug
fix release. The diff is large but it contains many fixes (See summary
in upstream's NEWS file) and Slurm minor releases have always been
considered safe. Besides, Slurm 16.05.9-1 has stayed in Unstable for a
while now without issues.

Can you please consider unblocking slurm-llnl?

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru slurm-llnl-16.05.8/debian/changelog 
slurm-llnl-16.05.9/debian/changelog
--- slurm-llnl-16.05.8/debian/changelog 2017-01-07 02:40:23.0 +0100
+++ slurm-llnl-16.05.9/debian/changelog 2017-02-03 09:50:02.0 +0100
@@ -1,3 +1,10 @@
+slurm-llnl (16.05.9-1) unstable; urgency=medium
+
+  * New upstream release
+  * Overrides spelling-error-in-binary false positives
+
+ -- Gennaro Oliva   Fri, 03 Feb 2017 09:50:02 +0100
+
 slurm-llnl (16.05.8-1) unstable; urgency=medium
 
   * New upstream release 
diff -Nru slurm-llnl-16.05.8/debian/libslurm30.lintian-overrides 
slurm-llnl-16.05.9/debian/libslurm30.lintian-overrides
--- slurm-llnl-16.05.8/debian/libslurm30.lintian-overrides  2017-01-04 
23:42:58.0 +0100
+++ slurm-llnl-16.05.9/debian/libslurm30.lintian-overrides  2017-02-02 
09:41:24.0 +0100
@@ -12,3 +12,4 @@
 # This happens because because slurm_job_preempt_mode is contained in
 # /usr/sbin/slurmctld and will never be referenced when running sinfo.
 hardening-no-bindnow
+spelling-error-in-binary
diff -Nru slurm-llnl-16.05.8/debian/libslurmdb30.lintian-overrides 
slurm-llnl-16.05.9/debian/libslurmdb30.lintian-overrides
--- slurm-llnl-16.05.8/debian/libslurmdb30.lintian-overrides2017-01-04 
23:42:58.0 +0100
+++ slurm-llnl-16.05.9/debian/libslurmdb30.lintian-overrides2017-02-02 
09:41:24.0 +0100
@@ -12,3 +12,4 @@
 # This happens because because slurm_job_preempt_mode is contained in
 # /usr/sbin/slurmctld and will never be referenced when running sinfo.
 hardening-no-bindnow
+spelling-error-in-binary
diff -Nru slurm-llnl-16.05.8/debian/slurm-client-emulator.lintian-overrides 
slurm-llnl-16.05.9/debian/slurm-client-emulator.lintian-overrides
--- slurm-llnl-16.05.8/debian/slurm-client-emulator.lintian-overrides   
2017-01-04 23:42:58.0 +0100
+++ slurm-llnl-16.05.9/debian/slurm-client-emulator.lintian-overrides   
2017-02-02 09:41:24.0 +0100
@@ -1 +1,2 @@
 slurm-client-emulator: hardening-no-bindnow
+spelling-error-in-binary
diff -Nru slurm-llnl-16.05.8/debian/slurm-client.lintian-overrides 
slurm-llnl-16.05.9/debian/slurm-client.lintian-overrides
--- slurm-llnl-16.05.8/debian/slurm-client.lintian-overrides2017-01-04 
23:42:58.0 +0100
+++ slurm-llnl-16.05.9/debian/slurm-client.lintian-overrides2017-02-02 
09:41:24.0 +0100
@@ -1,3 +1,4 @@
 slurm-client: manpage-has-errors-from-man
 slurm-client: conflicts-with-version
 slurm-client: hardening-no-bindnow
+spelling-error-in-binary
diff -Nru slurm-llnl-16.05.8/debian/slurmctld.lintian-overrides 
slurm-llnl-16.05.9/debian/slurmctld.lintian-overrides
--- slurm-llnl-16.05.8/debian/slurmctld.lintian-overrides   2017-01-04 
23:42:58.0 +0100
+++ slurm-llnl-16.05.9/debian/slurmctld.lintian-overrides   2017-02-02 
09:41:24.0 +0100
@@ -1,2 +1,3 @@
 slurmctld: possible-documentation-but-no-doc-base-registration
 slurmctld: hardening-no-bindnow
+spelling-error-in-binary
diff -Nru slurm-llnl-16.05.8/debian/slurmdbd.lintian-overrides 
slurm-llnl-16.05.9/debian/slurmdbd.lintian-overrides
--- slurm-llnl-16.05.8/debian/slurmdbd.lintian-overrides2017-01-04 
23:42:58.0 +0100
+++ slurm-llnl-16.05.9/debian/slurmdbd.lintian-overrides2017-02-02 
09:41:24.0 +0100
@@ -1 +1,2 @@
 slurmdbd: hardening-no-bindnow
+spelling-error-in-binary
diff -Nru slurm-llnl-16.05.8/debian/slurmd.lintian-overrides 
slurm-llnl-16.05.9/debian/slurmd.lintian-overrides
--- slurm-llnl-16.05.8/debian/slurmd.lintian-overrides  2017-01-04 
23:42:58.0 +0100
+++ slurm-llnl-16.05.9/debian/slurmd.lintian-overrides  2017-02-02 
09:41:24.0 +0100
@@ -1 +1,2 @@
 slurmd: hardening-no-bindnow
+spelling-error-in-binary
diff -Nru slurm-llnl-16.05.8/debian/slurm-wlm-emulator.lintian-overrides 
slurm-llnl-16.05.9/debian/slurm-wlm-emulator.lintian-overrides
--- slurm-llnl-16.05.8/debian/slurm-wlm-emulator.lintian-overrides  
2017-01-04 23:42:58.0 +0100
+++ slurm-llnl-16.05.9/debian/slurm-wlm-emulator.lintian-overrides  
2017-02-02 09:41:24.0 +0100
@@ -1 +1,2 @@
 slurm-wlm-emulator: 

Bug#836127: Call for Votes for new CTTE Member

[Mehdi Dogguy]

Hi Philip,

On 10/04/2017 10:37, Philip Hands wrote:
> Margarita Manterola  writes:
> 
>>> ===BEGIN
>>>
>>> The Technical Committee recommends that David Bremner  be
>>> appointed by the Debian Project Leader to the Technical Committee.
>>>
>>> A: Recommend to Appoint David Bremner 
>>> B: Further Discussion
>>>
>>> ===END
>>
>> I vote A > B
> 
> So, with that vote added, option A defeats B by 4 votes, and we thus
> agree to recommend David for the TC.
> 
> Mehdi, does this count as sufficiant notification of that fact?
> 

Yes, thank you for the notification. I'm happy to follow TC's
recommendation and appoint David as a new member of the team.
I'll issue a d-d-a mail soon.

Cheers,

-- 
Mehdi

Bug#843409: dose-builddebcheck --deb-triplettable needs to move to tupletable

[Mehdi Dogguy]

Hi,

On 10/01/2017 08:58, Ralf Treinen wrote:
> Hi Josch,
> 
> On Mon, Jan 09, 2017 at 05:57:27PM +0100, Johannes Schauer wrote:
>> Hi Ralf,
>>
>> On Sun, 6 Nov 2016 14:56:51 +0100 Helmut Grohne  wrote:
>>> dose-builddebcheck has a built-in architecture table and allows
>>> replacing that by supplying --deb-triplettable. Unfortunately, the
>>> triplettable and its format disappeared from Debian with the dpkg
>>> 1.18.11 upload. Now the file is called "tupletable" and has a different
>>> format (and a versioned format). Thus it is no longer possible to
>>> replace dose's internal architecture mapping.
>>
>> what do you say? Should we bump this bug to severity serious because
>> triplettables are completely abandoned in Stretch and the functionality will
>> thus be useless?
> 
> Please don't, it will kick dose out of stretch unless you can fix it rapidly.
> Severity=serious is not justified since the bug concerns IMHO only a very
> limited number of users.
> 

I think that this can be discussed with the Release Team to see whether they
would accept a fix for this bug (potentially after Feb 5th, if the patch is
not ready 10 days before the freeze). Trading a known broken feature with a
patch that might get the functionality back is not a big risk.

> Maybe we can ask Helmut to provide a patch?
> 

We can. Adding him in the loop (as I guess submitters are not automatically
subscribed to bugs).

Cheers,

-- 
Mehdi

Bug#610835: Installing caml pulls in half the world

[Mehdi Dogguy]

I thought we could finish 2016 with a nice discussion with Juliusz :-)

On 25/01/2011 19:25, Juliusz Chroboczek wrote:
> 
> While I have read the long descriptions after becoming confused by the
> short descriptions, and hence before sending the report, as you suggest
> above, I fail to see what this has to do with my complaint.
> 

Ok, so the bug is in the description. Could you please provide a patch which
enhances the descriptions and makes them less confusing?

Regards,

-- 
Mehdi

Bug#827518: ocaml: missing dependency on libncurses-dev

[Mehdi Dogguy]

Hi,

Thank you for your bugreport and apologies for not getting back to you
sooner.

On 17/06/2016 12:07, whitequark wrote:
> Source: ocaml
> Severity: normal
> 
> Dear Maintainer,
> 
> The ocaml package, as well as its sister packages ocaml-nox, ocaml-base and
> ocaml-base-nox, are missing a dependency on libncurses-dev. This is apparent
> when trying to build a bytecode executable with an embedded custom runtime:
> 
>   $ touch t.ml
>   $ ocamlc t.ml -custom
>   /usr/bin/ld: cannot find -lcurses
>   collect2: error: ld returned 1 exit status
>   File "t.ml", line 1:
>   Error: Error while building custom runtime system
> 
> Because of this, packages that assume that they can build a custom runtime
> whenever they can build regular bytecode executables, which is in my opinion
> a fair assumption, break. A notable case where this presents a significant
> problem is when the OPAM package manager is used with a system OCaml compiler.
> Many notable packages, e.g. ocamlfind and lwt, build custom runtimes, and
> currently the OPAM packages have to be altered to either disable that, when
> possible, or else add an explicit dependency on ncurses-dev, through
> the depext mechanism, which integrates OPAM with APT.
> 

I acknowledge the problem. IIUI, the fix you're looking for is to move the
dependency on libncurses5-dev from ocaml-nox to ocaml-base-nox. But this raises
another question, why ocaml-base-nox is used to compile packages. Its
description contains the following bits:

 This package contains only the runtime system needed to run bytecode
 executables that do not use the graphics library. The 'ocaml' package
 contains the full development suite of Objective Caml.

while ocaml-nox's description has:

 This package contains everything needed to develop OCaml applications
 that do not require the graphics library.

So, if you are trying to build ocaml binaries, ocaml-nox should be preferred
over ocaml-base-nox.

What do you think?

Regards,

-- 
Mehdi

Bug#418965: package confluence

[Mehdi Dogguy]

On 21/12/2016 20:59, Ralf Treinen wrote:
> Hi Mehdi,
> 
> On Wed, Dec 21, 2016 at 03:09:10PM +0100, Mehdi wrote:
>> Hi Ralf,
>>
>> Did you ask for its removal?
>>
>> FWIW, i'm also for its removal from debian since the project is dead 
>> upstream.
> 
> not yet, since there still is a recommendation of confluence from 
> the package science-electronics. I have removed this recommendation
> in the git of debian-science, but I do not know when that package
> will be updated.

I do not think it is a blocker.

-- 
Mehdi

Bug#841961: nmu: ocaml_4.02.3-7

[Mehdi Dogguy]

On 24/10/2016 22:07, Gilles Filippini wrote:
> Please rebuild ocaml against the pie-enabled compiler chain, to fix an FTBFS
> of scilab package:
> 

FWIW, I have uploaded ocaml/4.02.3-8 to fix issues on armhf this morning. And I
have just given back scilab on armhf. It /should/ fix scilab's build failure
there.

Regards,

-- 
Mehdi



signature.asc
Description: OpenPGP digital signature

Bug#837359: ocaml: FTBFS on -fPIE binNMU on armhf - test failure

[Mehdi Dogguy]

On 06/11/2016 10:19, Adrian Bunk wrote:
> On Sun, Nov 06, 2016 at 09:59:20AM +0100, Mehdi Dogguy wrote:
>> I've tried a rebuild on harris with pic_code set to true for arm. The build
>> succeeded and all tests passed fine. Do you want to run more tests or should
>> I upload this change?
> 
> Please upload.
> 

I just noticed Ximin did the same (and pushed it)... I'll re-use his patch and
upload shortly.

Regards,

-- 
Mehdi

Bug#841758: ocamldsort: FTBFS: relocation R_X86_64_32 against symbol `caml_backtrace_last_exn' can not be used when making a shared object; recompile with -fPIC

[Mehdi Dogguy]

Salut Ralf,

On 06/11/2016 08:27, Ralf Treinen wrote:
> Salut Mehdi,
> 
> On Sat, Nov 05, 2016 at 06:36:06PM +0100, Mehdi Dogguy wrote:
>> Hi Ralf,
>>
>> On Tue, Oct 25, 2016 at 09:08:34AM +0200, Ralf Treinen <trei...@free.fr> 
>> wrote:
>>> Hi Chris,
>>>
>>> On Sun, Oct 23, 2016 at 09:00:09AM +0100, Chris Lamb wrote:
>>>
>>>> ocamldsort fails to build from source in unstable/amd64:
>>>
>>> it compiles with ocaml 4.03.0 from experimental.
>>>
>>
>> Did you understood what actually makes it fail? It builds fine in a clean
>> chroot on my machine (dunno by which miracle).
> 
> No, I do not what this was due to, but if I remember right I could
> reproduce the bug reported by Chris with ocaml 4.02.

I think I understood what happened:
- The first build failure seen by Chris was due to PIE enabled by default in
GCC. Hence, the relocation error emitted by the linker.
- Some time later, OCaml has been binNMUed and that error got "fixed".
- But, a new error appeared (which we see on buildds) and has to do with the
switch to debhelper compat level 10 which enables parallel builds by default.

I've tested on my machine with -j8, and I was able to reproduce the build
failure as seen on buildds. That's the only issue left and I think my -5
upload will fix it.

Eventually, I think we should convince upstream to change the build-system.
I was able to build a functional ocamldsort by using ocamlbuild:

 ocamlbuild -pp camlp4o -package unix main.native

It is way simpler and is not subject to failures as seen using the Makefile.
For now, I've just forced parallel=1 in debian/rules to avoid the FTBFS.

Regards,

-- 
Mehdi

Bug#837456: ocamlgraph needs PIE binNMU

[Mehdi Dogguy]

Control: reassign -1 src:ocaml
Control: merge 837359 -1
Control: affects -1 src:ocamlgraph

Hi,

On 24/10/2016 19:04, Adrian Bunk wrote:
> Control: rassagn -1 src:ocamlgraph
> Control: affects -1 src:frama-c
> Control: retitle -1 ocamlgraph needs PIE binNMU
> 
> A binNMU is sufficient to fix this, and already requested.
> 

The binNMU has been scheduled and the only missing issue is to do with PIC on
armhf. The issue needs to be fixed in OCaml only. Hence, I am reassigning the
bug. Once OCaml is fixed on armhf, ocamlgraph could be given back to build.

Regards,

-- 
Mehdi

Bug#837359: ocaml: FTBFS on -fPIE binNMU on armhf - test failure

[Mehdi Dogguy]

Hi,

On 02/11/2016 03:22, Ximin Luo wrote:
> 
> let emit_load_symbol_addr dst s = if !Clflags.pic_code then begin [..] end
> else if !arch > ARMv6 && not !Clflags.dlcode && !fastcode_flag then begin `
> movw  {emit_reg dst}, #:lower16:{emit_symbol s}\n`; ` movt{emit_reg dst},
> #:upper16:{emit_symbol s}\n`; 2
> 
> Note that !arch in ocaml means "get the current value of the mutable
> reference 'arch'".
> 
> It looks like they already wrote the working code, it's just not being
> emitted here. So I just need to figure out how to make Cflags.pic_code true,
> which shouldn't be too hard. I will try this tomorrow when I'm less tired.
> 

I've tried a rebuild on harris with pic_code set to true for arm. The build
succeeded and all tests passed fine. Do you want to run more tests or should
I upload this change?

Regards,

-- 
Mehdi

Bug#840492: sexplib310: no longer builds libsexplib-camlp4-dev

[Mehdi Dogguy]

Control: clone 840492 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11
Control: notfound 840492 sexplib310/113.33.03-3
Control: reassign -1 pa-structural-sexp
Control: reassign -2 janest-core
Control: reassign -3 ocaml-ipaddr
Control: reassign -4 ocaml-re2
Control: reassign -5 janest-core-kernel
Control: reassign -6 pa-test
Control: reassign -7 custom-printf
Control: reassign -8 typerep
Control: reassign -9 otags
Control: reassign -10 janest-core-extended
Control: reassign -11 ocaml-textutils
Control: retitle -1 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -2 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -3 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -4 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -5 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -6 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -7 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -8 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -9 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -10 FTBFS: libsexplib-camlp4-dev is no longer available
Control: retitle -11 FTBFS: libsexplib-camlp4-dev is no longer available
Control: close 840492

On Wed, Oct 12, 2016 at 09:59:23AM +0200, Emilio Pozuelo Monfort 
<po...@debian.org> wrote:
> Please file bugs against those (or fix them directly if you maintain
> them) or make libsexplib-ocaml-dev provide libsexplib-camlp4-dev.
> 

libsexplib-camlp4-dev is gone for good. So, there is nothing to fix in sexplib
and reverse dependencies have to be fixed. Hence, closing this bugreport
and opening required new bugreports.

Regards,

-- 
Mehdi Dogguy

Bug#841758: ocamldsort: FTBFS: relocation R_X86_64_32 against symbol `caml_backtrace_last_exn' can not be used when making a shared object; recompile with -fPIC

[Mehdi Dogguy]

Hi Ralf,

On Tue, Oct 25, 2016 at 09:08:34AM +0200, Ralf Treinen <trei...@free.fr> wrote:
> Hi Chris,
> 
> On Sun, Oct 23, 2016 at 09:00:09AM +0100, Chris Lamb wrote:
> 
> > ocamldsort fails to build from source in unstable/amd64:
> 
> it compiles with ocaml 4.03.0 from experimental.
> 

Did you understood what actually makes it fail? It builds fine in a clean
chroot on my machine (dunno by which miracle).

The errors orginally reported by Chris are also not the same seen on the
buildds.

Regards,

-- 
Mehdi Dogguy

Bug#828549: SLURM OpenSSL 1.1 issue - Patch to disable OpenSSL support until upstream fixes

[Mehdi Dogguy]

Hi,

On 2016-11-03 01:32, Karl Kornel wrote:


Unfortunately, I don’t think your patch would be able to work
directly, because the quilt build process requires that the original
code be untouched; all of the changes to source have to be Quilt
patches.  So, I’ve taken your patch and converted it into a quilt
patch!  I’m attaching to this email a Git commit patch that creates
the quilt patch, and updates the patch series list.



You don't have to convert it. It can be used by Quilt as-is.


* Anyone who wants to test on Jessie or Xenial can use one of the
builds that I made.


The changes are targeted for Stretch. I don't see any reason to test
with Jessie. Did I miss something?


* In the meantime, if Gennaro decides to go forward with your code, he
could use the quilt patch I’ve attached here.



I've had a quick chat on IRC with Gennaro and I know he is working on
a backward compatible patch to make it work with both OpenSSL 1.0 and 
1.1.

So I'd wait until he is ready. In the worst case scenario, we can still
fallback to OpenSSL 1.0 to give us more time to work on the patch.

Regards,

--
Mehdi

Bug#837674: parmap: FTBFS with bindnow and PIE enabled

[Mehdi Dogguy]

Hi,

On 13/09/2016 14:12, Balint Reczey wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64 with patched GCC and dpkg.
> 
> The rebuild tested if packages are ready for a transition
> enabling PIE and bindnow for amd64.
> 

FWIW, I've tried to rebuild parmap in a clean Sid chroot and I am unable
to reproduce the build failure. You can find attached my build log.

Does it still fail for you?

Regards,

-- 
Mehdi
dpkg-buildpackage: info: source package parmap
dpkg-buildpackage: info: source version 1.0~rc7-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Mehdi Dogguy <me...@debian.org>
 dpkg-source --before-build parmap
dpkg-source: info: applying 0001-Update-version-number-in-various-places.patch
 fakeroot debian/rules clean
dh --with ocaml clean
dh: Compatibility levels before 9 are deprecated (level 7 in use)
   dh_testdir
   dh_auto_clean
dh_auto_clean: Compatibility levels before 9 are deprecated (level 7 in use)
   dh_ocamlclean
   dh_clean
dh_clean: Compatibility levels before 9 are deprecated (level 7 in use)
 dpkg-source -b parmap
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building parmap using existing ./parmap_1.0~rc7.orig.tar.gz
dpkg-source: info: building parmap in parmap_1.0~rc7-1.debian.tar.xz
dpkg-source: info: building parmap in parmap_1.0~rc7-1.dsc
 dpkg-genchanges --build=source >../parmap_1.0~rc7-1_source.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build parmap
dpkg-source: info: unapplying 0001-Update-version-number-in-various-places.patch
dpkg-buildpackage: info: full upload (original source is included)
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.3985
I: forking: cp -al /var/cache/pbuilder/cows/unstable-amd64/ 
/var/cache/pbuilder/build/cow.3985
I: unlink for ilistfile /var/cache/pbuilder/build/cow.3985/.ilist failed, 
it didn't exist?
I: forking: chroot /var/cache/pbuilder/build/cow.3985 cowdancer-ilistcreate 
/.ilist 'find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a 
-links +1 -print0 \) | xargs -0 stat --format '%d %i ''
I: Invoking pbuilder
I: forking: pbuilder build --debbuildopts  --debbuildopts  --buildplace 
/var/cache/pbuilder/build/cow.3985 --buildresult 
/var/cache/pbuilder/result/unstable-amd64 --no-targz --internal-chrootexec 
'chroot /var/cache/pbuilder/build/cow.3985 cow-shell' 
/home/mehdi/Debian/pkg-ocaml-maint/parmap_1.0~rc7-1.dsc
I: Running in no-targz mode
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Thu Nov  3 01:03:38 CET 2016
I: pbuilder-time-stamp: 1478131418
I: copying local configuration
I: mounting /proc filesystem
I: mounting /sys filesystem
I: mounting /run/shm filesystem
I: mounting /dev/pts filesystem
I: Mounting /var/cache/pbuilder/result/
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Installing the build-deps
W: execute priv not set on file D09custompool, not executing.
I: user script /var/cache/pbuilder/build/cow.3985/tmp/hooks/D10aptupdate 
starting
Hit:1 http://debian.univ-lorraine.fr/debian unstable InRelease
Reading package lists...
I: user script /var/cache/pbuilder/build/cow.3985/tmp/hooks/D10aptupdate 
finished
I: user script /var/cache/pbuilder/build/cow.3985/tmp/hooks/D11unsafeio 
starting
Setting force-unsafe-io for dpkg
I: user script /var/cache/pbuilder/build/cow.3985/tmp/hooks/D11unsafeio 
finished
W: execute priv not set on file D12aptupgrade, not executing.
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team <pbuilder-ma...@lists.alioth.debian.org>
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 7.0.50~), ocaml-nox (>= 3.12.0~), dh-ocaml (>= 0.9~), 
ocaml-findlib, autoconf
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 11646 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on debhelper (>= 7.0.50~); howev

Bug#842776: libdose3-ocaml-dev is uninstallable

[Mehdi Dogguy]

Hi Johannes,

On 01/11/2016 08:04, Johannes Schauer wrote:
> Package: libdose3-ocaml-dev
> Version: 5.0.1-6
> Severity: grave
> Justification: renders package unusable
> 
> Hi,
> 
> libdose3-ocaml-dev in unstable depends on
> libocamlgraph-ocaml-dev-i0qi0:amd64. This is provided by
> libocamlgraph-ocaml-dev 1.8.6-1+b1 but a recent binNMU introduced
> libocamlgraph-ocaml-dev 1.8.6-1+b2. Thus, dose3 needs a rebuild with the
> new ocamlgraph version to fix this problem.
> 

Thanks for detecting this issue and filing the bug!

I may have missed something... but why not requesting a rebuild of the package
instead of opening this bug? Is there anything else to do besides doing the
binNMU?

-- 
Mehdi

Bug#828549: SLURM OpenSSL 1.1 issue - Patch to disable OpenSSL support until upstream fixes

[Mehdi Dogguy]

Hi,

On 02/11/2016 20:06, Karl Kornel wrote:
> forwarded 828549 https://bugs.schedmd.com/show_bug.cgi?id=3226 tags 828549 +
> patch thanks
> 
> Hello!
> 
> It looks like even the latest SLURM Debian package, 16.05.6-1, still has this
> issue. I tested with OpenSSL package version 1.1.0b-2, building on a sid
> COWbuilder.
> 
> The issue is being tracked upstream at this URL:
> 
> https://bugs.schedmd.com/show_bug.cgi?id=3226
> 

Thanks for the reference!

> The bug was filed on Oct. 31, and acknowledged on Nov. 1.
> 
> SLURM only uses OpenSSL in one place: To create “job step credentials”.
> However, this is not the default: the default is to have MUNGE create those
> credentials.
> 
> Since OpenSSL is only used in one place, and that’s not even as the default,
> I have created a Quilt patch which removes OpenSSL from the build entirely.
> Unfortunately, it’s not enough to change how we run ./configure; if the
> configure script sees an OpenSSL installation, it will use it, so I have to
> completely remove the test for OpenSSL, as well as the Makefile.am file that
> would trigger the compilation of OpenSSL-using code.
> 

I think it is easier to port Slurm to use OpenSSL 1.1. Attached is a tentative
patch that makes Slurm compile against OpenSSL 1.1. I haven't tested it
thoroughly and I would appreciate some help. In short, EVP_MD_CTX became opaque
in OpenSSL 1.1 and we cannot use it directly anymore. Similar fixes have been
applied to other softs.

Another way to avoid the bug in Debian is to use OpenSSL 1.0 by choosing
libssl1.0-dev in the Build-Depends line. It doesn't fix the issue but prevents
the system from removing it from testing.

Regards,

-- 
Mehdi
From: Mehdi Dogguy <me...@debian.org>
Date: Wed, 2 Nov 2016 22:54:38 +0100
Subject: Port to OpenSSL 1.1

---
 src/plugins/crypto/openssl/crypto_openssl.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/src/plugins/crypto/openssl/crypto_openssl.c b/src/plugins/crypto/openssl/crypto_openssl.c
index 2fa9767..87c0b55 100644
--- a/src/plugins/crypto/openssl/crypto_openssl.c
+++ b/src/plugins/crypto/openssl/crypto_openssl.c
@@ -179,7 +179,7 @@ extern int
 crypto_sign(void * key, char *buffer, int buf_size, char **sig_pp,
 		unsigned int *sig_size_p)
 {
-	EVP_MD_CTXectx;
+	EVP_MD_CTX*ectx;
 	int   rc= SLURM_SUCCESS;
 	int   ksize = EVP_PKEY_size((EVP_PKEY *) key);
 
@@ -188,17 +188,18 @@ crypto_sign(void * key, char *buffer, int buf_size, char **sig_pp,
 	 */
 	*sig_pp = xmalloc(ksize * sizeof(unsigned char));
 
-	EVP_SignInit(, EVP_sha1());
-	EVP_SignUpdate(, buffer, buf_size);
+	ectx = EVP_MD_CTX_create();
+	EVP_SignInit(ectx, EVP_sha1());
+	EVP_SignUpdate(ectx, buffer, buf_size);
 
-	if (!(EVP_SignFinal(, (unsigned char *)*sig_pp, sig_size_p,
+	if (!(EVP_SignFinal(ectx, (unsigned char *)*sig_pp, sig_size_p,
 			(EVP_PKEY *) key))) {
 		rc = SLURM_ERROR;
 	}
 
 #ifdef HAVE_EVP_MD_CTX_CLEANUP
 	/* Note: Likely memory leak if this function is absent */
-	EVP_MD_CTX_cleanup();
+	EVP_MD_CTX_destroy(ectx);
 #endif
 
 	return rc;
@@ -208,13 +209,14 @@ extern int
 crypto_verify_sign(void * key, char *buffer, unsigned int buf_size,
 		char *signature, unsigned int sig_size)
 {
-	EVP_MD_CTX ectx;
+	EVP_MD_CTX *ectx;
 	intrc;
 
-	EVP_VerifyInit(, EVP_sha1());
-	EVP_VerifyUpdate(, buffer, buf_size);
+	ectx = EVP_MD_CTX_create();
+	EVP_VerifyInit(ectx, EVP_sha1());
+	EVP_VerifyUpdate(ectx, buffer, buf_size);
 
-	rc = EVP_VerifyFinal(, (unsigned char *) signature,
+	rc = EVP_VerifyFinal(ectx, (unsigned char *) signature,
 		sig_size, (EVP_PKEY *) key);
 	if (rc <= 0)
 		rc = SLURM_ERROR;
@@ -223,7 +225,7 @@ crypto_verify_sign(void * key, char *buffer, unsigned int buf_size,
 
 #ifdef HAVE_EVP_MD_CTX_CLEANUP
 	/* Note: Likely memory leak if this function is absent */
-	EVP_MD_CTX_cleanup();
+	EVP_MD_CTX_destroy(ectx);
 #endif
 
 	return rc;

Bug#836246: Acknowledgement (libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop)

[Mehdi Dogguy]

On 06/10/2016 00:32, John Paul Adrian Glaubitz wrote:
> On 10/06/2016 12:21 AM, Mehdi Dogguy wrote:
>> I have read your message, and I can understand it can be difficult at
>> time to deal with recurrent bugreports. But, I do not feel comfortable
>> with the way you expressed your frustration. And it is not acceptable
>> to use those terms to communicate with our community (and users).
> 
> Was this now escalated to you after I did not agree with larjona@d.o?
> 

No. In fact, I was not in contact with larjona lately at all, tbh.

> I'm a bit shocked to be honest how much I'm being prosecuted down for
> this! We should really start wondering where the code of conduct
> ends and the censorship and the paternalism starts.
> 

My intention was not to make you feel prosecuted. I am sorry if you
feel it that way.

> Again, I did not attack anyone directly, I was swearing in public
> and I think this is something which is covered by freedom of speech.
> 

I believe that your original message did hurt some people, even if it
wasn't directed towards anybody specifically. So freedom of speech is
guaranteed as long as nobody feels attacked, hurt or shocked. And, CoC
is not meant to censor anyone. It is a tool to ensure that we interact
in a pleasant and welcoming environment, for the maximum of people.

> I'm not going to comment further on this. I'm also no longer subscribed
> to the pkg-mate-team mailing list and I will most likely also leave
> the team because I honestly didn't just feel annoyed but outright
> harassed by those people you abuse the Debian bug tracker as their
> personal support ticket system. Those aren't just lapses and oversights,
> this is outright laziness and malicious entitlement by those people.
> 

We are not forced to reply to every bug. We have also ways to ensure that
specific people are banned from interacting with the BTS and mailing lists
if we show they have a malicious behavior, by contacting BTS admins and
listmasters. We all feel the same when some minority abuses some system.
Some maintainers know better how to deal with those. I believe it is better
to ignore those abusers instead of swearing.

All best,

-- 
Mehdi

Bug#836246: Acknowledgement (libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop)

[Mehdi Dogguy]

Hi John,

I have read your message, and I can understand it can be difficult at
time to deal with recurrent bugreports. But, I do not feel comfortable
with the way you expressed your frustration. And it is not acceptable
to use those terms to communicate with our community (and users).

Users may have send those bugreports in good faith, not just to annoy
you. Having such bugreports is also a good way to evaluate the impact
of the bug (admittedly, it may be obvious in this specific case).

As a project, we have adopted a Code of Conduct [1] for participants
to our mailinglists, IRC channels and other communication means. We
expect our users to respect it. And, more importantly, I expect our
project members to defend it.

I would like to ask you to think about this and I'd like to count on
you to have more calm exchanges in the future. It is collectively
important, for both contributors and users, to be able to interact in
a safe and pleasant environment. We are all here to make fun! So
please, let's make it enjoyable the best we can.

[1] https://www.debian.org/code_of_conduct

All best,

-- 
Mehdi Dogguy

Bug#830344: How should the TC help with a project roadmap?

[Mehdi Dogguy]

(I noticed that you replied to the list, and not to the bugreport. I
took the liberty to send my reply to the bug as well to have a complete
log of the discussion. Feel free to drop the list in the subsequent replies).

On 04/08/2016 22:22, Tollef Fog Heen wrote:
> 
> One thing I don't think we're in complete agreement about is which
> problem we're trying to solve with the roadmap.  Is it to gather
> enthusiasm?  Is it to steer Debian better?  Is it to communicate to
> commercial partners like HPE?  Something else?  I think we need to agree
> on that before we try to agree on the mechanism to achieve it.
> 

This is a very good question indeed. The main goal of the roadmap is
none of those. What you listed are desirable (and expected) side
effects. The main goal is to document time-limited technical sub-projects
that might need more promotion and/or more manpower.

As I described it during my talk, a roadmap:
- reveals gaps between what we do and what we should be doing
- provides a strategic view, a vision to the project
- is a communication tool
- can be a recruitment platform.

Having a roadmap published, I expect us to:
- find new contributors by showing that our work doesn't focus solely on
  packaging. For example, porting [1] efforts are funny problems for programmers
  and I am not sure those easily find how to start in our project.
- give some insights about what we are doing and what we are planning to do
- be able to approach partners and potential sponsors with a concrete work plan
- an easy way to communicate about what we do (and about our progress)

I believe those are valuable goals and a roadmap will help us to achieve them.

[1] By porting, I mean both adapting code to work on new architectures and
migrating some code to new versions of some libraries.

Regards,

-- 
Mehdi

Bug#830344: How should the TC help with a project roadmap?

[Mehdi Dogguy]

On 03/08/2016 17:41, Ian Jackson wrote:
> Well, not _all_ of the bullet points above are things that the TC is
> (or could be) bad at.
> 
> But, in increasing order of likely controversy:
> 
>  * By my comments about "judgemental" I meant that a "helping people
>get their ideas done" team ought to try to avoid making technical
>judgements, especially adverse ones, about those ideas.
> 
>However, making technical judgements is the key function of the TC,
>and making them early, tentatively and informally is very valuable
>in the TC context.  In the context of a "new ideas enabling" team,
>early technical judgement (even if tentative and informal) risks
>sapping energy.
> 

Note that working on a roadmap does not necessarily call for making
judgments on ideas. Also, we should not be afraid of asking questions
about the proposed ideas/goals and not consider questions to be judgments.

Besides, as Debian Developers, we like to think about technical details
of implementation. So this risk is in fact general and not specifically
linked to the TC.

>  * It is inevitable that people are often unhappy with TC decisions.
>It is natural that TC members will tend to accumulate, if not
>actual "enemies", people who have serious qualms about their
>judgement.
> 

I am a little bothered with this specific point above. I do not expect TC
members to accumulate enemies over time. If people do not respect TC
decisions then we will have hard time explaining to them that they should
implement the decision. On the contrary, I really believe the TC is very
well respected in our project. People recognize the usefulness of their
work and respect their decisions once made public.

If some TC members accumulate "enemies" with time, then maybe some members
do not agree with a fundamental part of our constitution where the TC can
be called to overrule a developer. I believe people in that case are a real
minority (if they exist) and that we should not focus our attention on them.

>We can hope that usually people who are pleased by TC decisions are
>more numerous, but in the context of an "idea enablement" team, it
>is much more important that stakeholders don't have an initially
>negative view of the team members.
> 

I truly believe project members to not have an initial negative view of
the TC.

Regards,

-- 
Mehdi

Bug#830344: How should the TC help with a project roadmap?

[Mehdi Dogguy]

Hi Philip,

On 03/08/2016 10:47, Philip Hands wrote:
> Conflicting goals:
> 
>   Unless it's clear that both goals will be done unless one of them is
>   stopped, and they are going to be in conflict from the start, I think
>   it's normally best to let them compete.  As long as each effort is
>   aware of the other, then they can decide amongst themselves which is
>   going to fail in the end.  It's completely possible that of the two
>   efforts, one is clearly technically superior, but the other has more
>   enthusiastic people involved -- how does one choose which to stop?
>

>From a TC member, I find your question funny :-) I'd reply to your question
by: in the same way the TC used to do. Besides, it is not about which one
to stop, but which one to promote as a project goal.

> GR for the roadmap:
> 
>   If we need a centrally agreed list, then this seems like the best way
>   to do it, since it makes sure that a) all developers will be made
>   aware of the goals, and b) the ones that succeed have enough support
>   that even those that might be tempted to resist a goal should be
>   persuaded that many people want it to happen.
> 

I think I have replied to this in my reply to marga.

> Late conflict:
> 
>   This is a very important point.  If we can come up with a way of
>   avoiding this happening it would clearly be a benefit.
> 
> The "Let me help you do what you want team":
> 
>   That encapsulates what I think might be worthwhile out of this idea.
>   It emphasises letting people do things if they happen to feel the urge.
> 
> So, the problem I see with getting the TC involved with this process
> is that it emphasises the aspect of somehow seeking permission before
> proceeding.
> 

It is not about seeking permission since we are not looking for new ways
to stop people doing things. We are trying to promote their work, find
ways to enhance their ideas or put them in touch with other people that
might help them, (through the roadmap) communicate about what project
members are working on, and communicate on what we think is important to
achieve for the upcoming year(s). Having your idea on the roadmap also
helps to gather more supporters and organize sprints to develop it and
work on it. While this last point doesn't specifically need the roadmap
to hold true, it is much more convenient to encourage people to work on
specific identified subjects... than to encourage sprints on general
subjects.

> We don't really have a shortage of ideas in Debian, but we do have a
> shortage of effort to implement them.  If we can make it easier for
> people to go ahead and explore their idea for improving Debian, that's
> great.  If we can also help them avoid pitfalls, and help them promote
> their effort to get more people to help them, even better.
> 

I agree that we don't have a shortage of ideas in Debian. The problem
is that we don't necessarily communicate on our ideas. This makes it
even more difficult to find volunteers to work on it. So both points
(number of ideas vs. manpower) are linked, IMHO.

> Of course, that doesn't really advance the idea of a centralised and
> coherent roadmap.  I'm not too upset about that, since I think that
> lurking in the foundations of the idea of a coherent roadmap is the
> assumption that we can somehow predict which ideas are likely to
> succeed, and that we can somehow tell people to work on them.  I don't
> think either assumption is true, and that some good ideas will be lost
> if we set up any sort of filter.
> 

The assumption of maybe failing to detect successful ideas might be true
but I don't think it would prevent anyone to work on ideas that failed to
be on the roadmap. Your example of the Reproducible Builds is only
speculation and I fail to link it to reality, tbh. Again, the idea of the
roadmap is not to _decide_ which ideas people should _not_ work on, but
rather which ones should be promoted to gather more momentum.

Regards,

-- 
Mehdi

Bug#830344: How should the TC help with a project roadmap?

[Mehdi Dogguy]

Hi gregor,

On 14/07/2016 04:12, gregor herrmann wrote:
> On Mon, 11 Jul 2016 12:39:33 +0200, Margarita Manterola wrote:
> 
> (cc'ing leader@, withstanding the temptation to cc -project in order not to
> hijack the TC specific bug)
> 

FWIW, I am subscribed to -ctte mailing list.

>> Additionally, I suggested that a team (be it the TC or some other team)
>> could gather the list of goals and once a year let the project vote on it
>> through a GR, so that all goals that beat NOTA get approved. This proposal
>> was rejected as being too heavy handed.
> 
> I think this proposal has quite some merits.
> 
> IMO it boils down to what this roadmap and the goals are supposed to be, and
> I have the impression that this is not very clear and/or that there's no real
> consensus about this question.
> 
> My idea is that a roadmap is a document laying out the global direction of
> the project, and act as somewhat binding guidelines for all Debian
> contributors ("something we want to achieve together"); and not just a
> collection of random detailed technical changes.
> 
>> My reason for proposing this was that I feel developers will be more
>> engaged with the goals if they have voted for them than if they come from
>> an external team.
> 
> I agree on this reasoning. If the roadmap should be more than a list of
> "private" projects that can just be ignored, than it needs "buy 
> in"/legitimacy by the project members; and even if GRs are quite heavy-handed
> they're the only tool we have to take decisions as a project and to produce
> this legitimacy.
> 

I believe I replied to this point in my reply to marga in this bug (and also
partly later in this mail). Please let me know if there are other points I
didn't clarify.

>> During the BOF, a bunch of people volunteered to be part of the Roadmap
>> team, even though it was unclear what the Roadmap team should do and how it
>> should do that.
> 
> That was my impression too :)
> 
>> Initally, Mehdi wanted the TC to be the Roadmap team, but given the intent
>> of forming this other Roadmap team during the BOF, I don't know what is
>> currently expected of the TC.
> 
> IMO the TC is the wrong body for a roadmap, as I see it as an arbiter in
> cases of technical disputes, and the goals covered by the roadmap neither
> need to be technical nor controversial per se.
> 

Historically, we mainly used the TC that way indeed. I believe this was due
to a lack of a vision in our project, and the TC could engage in such higher
value tasks and set a direction to the project.

Working (openly) on a list of project goals has also the merits of describing
a context and a direction which helps to avoid some conflicts. So, it is a
pro-active way of solving potential problems.

> In the end, I think that a roadmap for the project lies in the responsibility
> of the DPL, i.e. that it's a genuine leadership task (and indeed it was
> proposed by our DPL already in his platform); of course it seems reasonable
> for Mehdi to seek support in the actual implementation of the process, e.g.
> from a group of people called "Roadmap Team".
> 

Yes, I agree. My reasoning led me to think that the TC is the best body to
handle this in Debian. We obviously disagree on this specific point, but I
am only explaining my reasoning. So I asked the current TC Chair to engage
a discussion with TC members and see if they share this thought. If not, it
will be done elsewhere, a "Roadmap Team". Since we are discussing setting a
direction for the project, I agree that the DPL should be actively working
on it. But there is some administrative and communication work to not
underestimate and I believe a delegated team or a roadmap helpers team would
be of a great help to drive this forward. This is not required if the TC
handles the roadmap though as they already have the constitutional powers to
decide on technical matters.

It is also quite common (elsewhere) to see a Technical Committee deciding on
a program or a roadmap. For conferences, the Technical Committee usually
reviews proposed papers, selects accepts papers, set the conference program,
etc... In companies, a Technical Committee also usually decides on the general
direction that should be implemented.

In my understanding, having the powers the overrule individuals in a project
or decide on technical matters where jurisdictions overlap are only tools to
be able to set a direction, and not the other way around.

It is true that we focused our attention on disputes and how to solve them,
which is a very valuable goal, but IMHO we lost sight on the bigger picture:
what we want to achieve in our project. We are not looking for expertise in
mediation and social problem solving. We want the project to stay relevant,
innovate and spread free software. (Yes, we have many implicit goals and
this is not an exhaustive list of course). Pursuing that goal, we should not
rely on individual project members to shine and share their vision on what
Debian should look 

Bug#830344: How should the TC help with a project roadmap?

[Mehdi Dogguy]

Hi marga,

On 11/07/2016 12:39, Margarita Manterola wrote:
> For documentation purposes, I list below my summary of the points that were
> raised during the Roadmap BOF. These items are separate and may not 
> necessarily
> all (or even any) need to be true in the implementation adopted. During the 
> BOF
> there were disagreements on almost all of them.
> 
> a. Proposals could be made using the DEP process
>(http://dep.debian.net/deps/dep0/)
> 
> b. Goals should have owners.
> 

I don't remember any disagreement over a. and b. The main remark about DEPs was
that it could be the tool to implement the roadmap, but it lacks a few things:
1. it is not obvious to measure progress of each DEP
2. the whole process looks abandoned, and nobody is taking care of it. It really
   needs to be managed. Some DEP drivers feel a bit lost because they don't know
   when a DEP should become "ACCEPTED".
3. a roadmap should show a list of subjects people are actively working on. It
  is not clear how to do that with dep.d.n
4. communication about new DEPs (and evolution of the list of DEPs in general)

If 1. and 3. are fixed, DEP could be a perfect _tool_ to implement a roadmap.
Still, we need people to look over ongoing DEPs/goals and fix 2. and 4.

> c. Goals should not be announced unless there's already work going on.
> 
> d. There could be a list of goals (with owners and work under way) and a
>wishlist (things that we consider a good idea, but haven't been started).
> 

IMHO, c. and d. are the same points. The consensus during the BoF was that
there could be very relevant and important ideas, but if there no drivers for
it then it should appear on a different list, which could be something else
than the roadmap.

> e. There should be clear tracking of what's going on with each goal.
> 

My feeling is that there was no disagreement over this specific point. At least,
I don't recall any. Can you refresh my memory? (I may have missed it).

The proposal was to work on S.M.A.R.T goals [1], like we did for Release Goals
in the past.

[1] https://en.wikipedia.org/wiki/SMART_criteria

> Additionally, I suggested that a team (be it the TC or some other team) could
> gather the list of goals and once a year let the project vote on it through a
> GR, so that all goals that beat NOTA get approved. This proposal was rejected 
> as
> being too heavy handed.
> 
> My reason for proposing this was that I feel developers will be more engaged
> with the goals if they have voted for them than if they come from an external
> team. However, as long as we are not forcing people to work on specific things
> (i.e. if the bugs related to the goal are not RC), I'm fine with the goals
> coming from whoever the roadmap team is.
> 

We share the same goal: We want developers to feel more engaged with the goals
and encourage others to work on them. The disagreement was only about the way
to reach it. As you say, the goal of a roadmap is *not* to turn down individual
initiatives. I fear that a vote will be counter-productive if some goals are
voted against.

Additionally, I am not sure how to interpret the results of a vote. What should
happen if the project votes aginst a roadmap with a dozen of goals? Should we
play this game over and over until some list gets through? Similarly, the
outcome will not be very clear if we vote for individual roadmap items (and
when some of them do not receive enough votes). We are not looking for ways to
block initiatives, but to foster innovation and collaborative work.

I guess the idea behind the vote is to give goals some momentum, increase
engagement, gather more supporters, etc And I agree that those points
are very important if we want to publish a project roadmap. I think that votes
are a poor way to achieve that. People will not be convinced about an idea just
because another set of people voted for it. Additionally, votes are not a way
to reach consensus, and that's really what we need for roadmap items (IMHO).

Votes tend to force a win/lose dichotomy and ignores the possibility of building
a compromise. I expect project members to discuss proposed goals and reach
consensus, and not simply block it with a vote because of a disagreement. A vote
may also isolate a minority, which is really not what we are trying to achieve
with the roadmap.

About RC-ness of bugs, it is the Release Team territory. I don't see a reason
to change that... especially, since roadmap goals are not necessarily bound to
a release. The RT is free to block a release waiting for some goal, but it is
their decision.

Saying all that and we forget an important historical data point : Release
Goals were proposed by project members and decided by a team. None of them
required a vote. It was required that a Release Goal should be generally
consensual, and it will be required for Project Goals (as noted in the gobby
"roadmap" document that was drafted during the BoF). Otherwise, it would be
difficult to call them "Project Goals" 

Bug#517109: grepmail: support for lzma compression

[Mehdi Dogguy]

On Wed, Feb 25, 2009 at 06:16:29PM +0100, Lucas Nussbaum 
<lu...@lucas-nussbaum.net> wrote:
> Package: grepmail
> Version: 5.3033-4
> Severity: wishlist
> 
> Hi,
> 
> lzma is known to produce better compression that bzip2. Could you please
> support it in grepmail?
>

Looks like it is fixed upsteam in 5.3100. It would be nice if someone
could adopt this package and update it to latest upstream version.

Bonus points if maintainer makes a backport too... ;)

Regards,

-- 
Mehdi Dogguy

Bug#820589: jessie-pu: package opam/1.2.0-1+deb8u1

[Mehdi Dogguy]

On 20/04/2016 11:50, Julien Cristau wrote:
> Control: tags -1 confirmed
> 
> On Mon, Apr 11, 2016 at 00:57:58 +0200, Mehdi Dogguy wrote:
> 
>> Hi,
>>
>> On 10/04/2016 17:27, Julien Cristau wrote:
>>>> --- a/debian/changelog
>>>> +++ b/debian/changelog
>>>> @@ -1,3 +1,10 @@
>>>> +opam (1.2.0-1+deb8u1) jessie; urgency=medium
>>>> +
>>>> +  * Stop using insecure and no-check-certificate flags when fetching
>>>> +files using wget and curl.
>>>> +
>>>
>>> Missing "closes:"?
>>>
>>
>> Fixed in attached new diff.
>>
> Looks fine, thanks.
> 

Uploaded, thanks!

-- 
Mehdi

Bug#820589: jessie-pu: package opam/1.2.0-1+deb8u1

[Mehdi Dogguy]

Hi,

On 10/04/2016 17:27, Julien Cristau wrote:
>> --- a/debian/changelog
>> +++ b/debian/changelog
>> @@ -1,3 +1,10 @@
>> +opam (1.2.0-1+deb8u1) jessie; urgency=medium
>> +
>> +  * Stop using insecure and no-check-certificate flags when fetching
>> +files using wget and curl.
>> +
> 
> Missing "closes:"?
> 

Fixed in attached new diff.

Cheers.

-- 
Mehdi
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+opam (1.2.0-1+deb8u1) jessie; urgency=medium
+
+  * Stop using insecure and no-check-certificate flags when fetching
+    files using wget and curl (Closes: #818081).
+
+ -- Mehdi Dogguy <me...@debian.org>  Sun, 10 Apr 2016 12:27:13 +0200
+
 opam (1.2.0-1) unstable; urgency=medium
 
   * New upstream release.
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,6 @@
 [DEFAULT]
+git-debian-branch = "debian/jessie"
+git-upstream-branch = "upstream/1.2.0"
 pristine-tar = True
 filter-pristine-tar = True
 filter = [
--- /dev/null
+++ b/debian/patches/0003-remove-insecure-no-check-certificate-flags.patch
@@ -0,0 +1,30 @@
+From: Mehdi Dogguy <me...@debian.org>
+Date: Sun, 10 Apr 2016 12:26:17 +0200
+Subject: remove insecure / no-check-certificate flags
+
+---
+ src/core/opamSystem.ml | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/core/opamSystem.ml b/src/core/opamSystem.ml
+index a8e3168..c4151e9 100644
+--- a/src/core/opamSystem.ml
 b/src/core/opamSystem.ml
+@@ -597,7 +597,7 @@ let download_command =
+   let wget ~compress:_ src =
+ let wget = [
+   "wget";
+-  "--content-disposition"; "--no-check-certificate";
++  "--content-disposition";
+   "-t"; retry;
+   src
+ ] in
+@@ -605,7 +605,7 @@ let download_command =
+   let curl command ~compress src =
+ let curl = [
+   command;
+-  "--write-out"; "%{http_code}\\n"; "--insecure";
++  "--write-out"; "%{http_code}\\n";
+   "--retry"; retry; "--retry-delay"; "2";
+ ] @ (if compress then ["--compressed"] else []) @ [
+ "-OL"; src
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 0001-Fix-some-spelling-errors.patch
 0002-Import-uutf-and-jsonm-temporarily.patch
+0003-remove-insecure-no-check-certificate-flags.patch

Bug#820589: jessie-pu: package opam/1.2.0-1+deb8u1

[Mehdi Dogguy]

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

Hi,

Following a recommendation from the Security team[1], I'd like to update
Opam in Jessie to fix #818081.

Please find attached my diff.

[1] https://lists.debian.org/debian-ocaml-maint/2016/04/msg00012.html

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+opam (1.2.0-1+deb8u1) jessie; urgency=medium
+
+  * Stop using insecure and no-check-certificate flags when fetching
+files using wget and curl.
+
+ -- Mehdi Dogguy <me...@debian.org>  Sun, 10 Apr 2016 12:27:13 +0200
+
 opam (1.2.0-1) unstable; urgency=medium
 
   * New upstream release.
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,6 @@
 [DEFAULT]
+debian-branch = "debian/jessie"
+upstream-branch = "upstream/1.2.0"
 pristine-tar = True
 filter-pristine-tar = True
 filter = [
--- /dev/null
+++ b/debian/patches/0003-remove-insecure-no-check-certificate-flags.patch
@@ -0,0 +1,30 @@
+From: Mehdi Dogguy <me...@debian.org>
+Date: Sun, 10 Apr 2016 12:26:17 +0200
+Subject: remove insecure / no-check-certificate flags
+
+---
+ src/core/opamSystem.ml | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/core/opamSystem.ml b/src/core/opamSystem.ml
+index a8e3168..c4151e9 100644
+--- a/src/core/opamSystem.ml
 b/src/core/opamSystem.ml
+@@ -597,7 +597,7 @@ let download_command =
+   let wget ~compress:_ src =
+ let wget = [
+   "wget";
+-  "--content-disposition"; "--no-check-certificate";
++  "--content-disposition";
+   "-t"; retry;
+   src
+ ] in
+@@ -605,7 +605,7 @@ let download_command =
+   let curl command ~compress src =
+ let curl = [
+   command;
+-  "--write-out"; "%{http_code}\\n"; "--insecure";
++  "--write-out"; "%{http_code}\\n";
+   "--retry"; retry; "--retry-delay"; "2";
+ ] @ (if compress then ["--compressed"] else []) @ [
+ "-OL"; src
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 0001-Fix-some-spelling-errors.patch
 0002-Import-uutf-and-jsonm-temporarily.patch
+0003-remove-insecure-no-check-certificate-flags.patch

Bug#803947: enigmail: completely broken after upgrade of gnupg2 to 2.1.9

[Mehdi Dogguy]

On Sun, Mar 20, 2016 at 06:58:34PM +0100, Mehdi Dogguy <me...@dogguy.org> wrote:
> On Thu, Nov 12, 2015 at 10:38:39AM +0100, IOhannes m zmölnig 
> <zmoel...@umlaeute.mur.at> wrote:
> > Control: severity -1 important
> > thanks.
> > 
> > i'm unable to reproduce the problem on my xfce4 machine.
> > 
> > therefore the severity of this bug-report can at most be "important"
> > ("a bug which has a major effect on the usability of a package, without
> > rendering it completely unusable to everyone").
> > 
> > "grave" is a bit over the top ("makes the package in question unusable
> > or mostly so, or causes data loss, or introduces a security hole
> > allowing access to the accounts of users who use the package").
> > 
> 
> I am also experiencing the same bug. I cannot sign or encrypt messages
> using Enigmail (enigmail and icedove from Stretch). Decrypting messages
> doesn't work too.
>

FWIW, my issue was related to https://bugs.gnupg.org/gnupg/issue1983

So nothing to do with Enigmail, except for the pretty useless error message.

-- 
Mehdi Dogguy

Bug#803947: enigmail: completely broken after upgrade of gnupg2 to 2.1.9

[Mehdi Dogguy]

On Thu, Nov 12, 2015 at 10:38:39AM +0100, IOhannes m zmölnig 
<zmoel...@umlaeute.mur.at> wrote:
> Control: severity -1 important
> thanks.
> 
> i'm unable to reproduce the problem on my xfce4 machine.
> 
> therefore the severity of this bug-report can at most be "important"
> ("a bug which has a major effect on the usability of a package, without
> rendering it completely unusable to everyone").
> 
> "grave" is a bit over the top ("makes the package in question unusable
> or mostly so, or causes data loss, or introduces a security hole
> allowing access to the accounts of users who use the package").
> 

I am also experiencing the same bug. I cannot sign or encrypt messages
using Enigmail (enigmail and icedove from Stretch). Decrypting messages
doesn't work too.

Enigmail is still able to check validity of a signature though.

I agree that it still does something, but I would not call the package
usable. Its main purpose is really not to check signatures, but to
help signing/encrypting messages. So the severity should reflect that.

Regards,

-- 
Mehdi Dogguy

Bug#818331: aac-tactics: FTBFS: constructor vcons (in type vT) expects 2 arguments

[Mehdi Dogguy]

Control: forcemerge 813459 818331

Hi,

On 16/03/2016 02:13, Martin Michlmayr wrote:
> Package: aac-tactics
> Version: 0.4-5
> Severity: serious
> 
> This package fails to build in unstable:
> 
>> sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux
> ...
>> make[4]: Entering directory '/<>'
>> "coqc"  -q -opt -R "." AAC_tactics   AAC
>> File "./AAC.v", line 497, characters 8-20:
>> Error: The constructor vcons (in type vT) expects 2 arguments.
>> Makefile.coq:424: recipe for target 'AAC.vo' failed
>> make[4]: *** [AAC.vo] Error 1
>> make[4]: Leaving directory '/<>'
> 

This looks like a duplicate of #813459.

Regards,

-- 
Mehdi

Bug#802264: src:matita: FTBFS with OCaml 4.02.3

[Mehdi Dogguy]

Hi Claudio,

On 25/01/2016 20:54, Claudio Sacerdoti Coen wrote:
> Dear Mehdi,
> 
> the most recent camlp5 version in git seems to fix enough bugs to let

Thanks for handling this with camlp5's upstream. I can confirm it builds
fine with latest two fixes in camlp5. I'll prepare fixed packages now and
will upload shortly.

> the version of matita in Debian compile.
> 

Is there any more recent version to take into account? For now, we have
matita 0.99.1. What is the status of the project?

Kind regards,

-- 
Mehdi

Bug#812178: FTBFS: The implementation hExtlib.ml does not match the interface hExtlib.cmi

[Mehdi Dogguy]

Control: reassign 812178 camlp5
Control: severity 812178 important
Control: found 812178 camlp5/6.14-1
Control: fixed 812178 camlp5/6.14-2

On 21/01/2016 09:25, Mehdi Dogguy wrote:
> Trying to build matita with a fixed camlp5 package that includes upstream
> fix (caca3dd0643ec5aae9df4399fa73eb280808ef18) fails with the following
> error:
> 
>   OCAMLC hExtlib.ml
>   File "hExtlib.ml", line 463, characters 10-23:
>   Warning 3: deprecated: String.create
>   Use Bytes.create instead.
>   File "hExtlib.ml", line 1:
>   Error: The implementation hExtlib.ml
>  does not match the interface hExtlib.cmi:
>  Values do not match:
>val find : ?test:(string -> bool) -> string -> string list
>  is not included in
>val find : ?test: -> string -> string list
>  File "hExtlib.ml", line 530, characters 4-8: Actual declaration
>   ../Makefile.common:99: recipe for target 'hExtlib.cmo' failed
>   make: *** [hExtlib.cmo] Error 2
> 
> I have to admit that the error is quite strange and the cause might not
> be a bug in matita but elsewhere. I am assigning the bug to matita as
> it is the only package affected by this and until the root cause is
> correctly identified.
> 

Bug found and fixed in camlp5. Thus, reassigning to the correct package.

-- 
Mehdi

Bug#812178: FTBFS: The implementation hExtlib.ml does not match the interface hExtlib.cmi

[Mehdi Dogguy]

Package: matita
Version: 0.99.1-3
Severity: serious

Dear Maintainer,

Trying to build matita with a fixed camlp5 package that includes upstream
fix (caca3dd0643ec5aae9df4399fa73eb280808ef18) fails with the following
error:

  OCAMLC hExtlib.ml
  File "hExtlib.ml", line 463, characters 10-23:
  Warning 3: deprecated: String.create
  Use Bytes.create instead.
  File "hExtlib.ml", line 1:
  Error: The implementation hExtlib.ml
 does not match the interface hExtlib.cmi:
 Values do not match:
   val find : ?test:(string -> bool) -> string -> string list
 is not included in
   val find : ?test: -> string -> string list
 File "hExtlib.ml", line 530, characters 4-8: Actual declaration
  ../Makefile.common:99: recipe for target 'hExtlib.cmo' failed
  make: *** [hExtlib.cmo] Error 2

I have to admit that the error is quite strange and the cause might not
be a bug in matita but elsewhere. I am assigning the bug to matita as
it is the only package affected by this and until the root cause is
correctly identified.

Regards,

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#790422: Parsing.Parse_error

[Mehdi Dogguy]

On 2016-01-20 01:14, Mehdi Dogguy wrote:

Hi,

On 19/01/2016 23:07, Christoph Berg wrote:


Long story, but that's the real-world example here. In fact I'm
considering upgrading the apt.pg.o build host to stretch just because
of this bugfix, and because a backport of the current dose-debcheck
version to jessie looks too hard.



After seeing your message, I was curious and tried to backport it. I 
still
didn't get it to compile because of some weird OCaml feature but I 
think

all what is left to do is to backport extlib (which is easy).

See file attached. Changes in "applications/distcheck.ml" should not be
kept. That's the part that will require a newer Extlib if a workaround 
cannot

be found.



Updated patch, without the changes in "applications/distcheck.ml".

Regards,

--
Mdiff --git a/Makefile.config.in b/Makefile.config.in
index 8d3496b..8fdda2d 100644
--- a/Makefile.config.in
+++ b/Makefile.config.in
@@ -4,7 +4,7 @@ NAME=@PACKAGE_NAME@
 CFLAGS=@CFLAGS@ -fPIC -Wall -pedantic -Werror -Wno-long-long -warn-error FPSXY
 CPPFLAGS=@CPPFLAGS@
 LDFLAGS=@LDFLAGS@
-CPPOFLAGS=-V OCAML:$(shell ocamlc -version)
+CPPOFLAGS=
 
 
 OCAMLFIND=@OCAMLFIND@
diff --git a/algo/diagnostic.ml b/algo/diagnostic.ml
index 1ddd728..5ffb920 100644
--- a/algo/diagnostic.ml
+++ b/algo/diagnostic.ml
@@ -525,8 +525,7 @@ let print_error ?(condense=false) ?(minimal=false) pp root 
fmt l =
   open Defaultgraphs.SyntacticDependencyGraph
   type label = G.E.label
   type t = int
-  type edge = G.E.t
-  let weight e = match G.E.label e with { contents = PkgE.Conflict _ } -> 
1000 | _ -> 0
+  let weight e = match !e with PkgE.Conflict _ -> 1000 | _ -> 0
   let compare = Pervasives.compare
   let add = (+)
   let zero = 0
diff --git a/algo/dominators.ml b/algo/dominators.ml
index d7be032..872f03c 100644
--- a/algo/dominators.ml
+++ b/algo/dominators.ml
@@ -101,11 +101,7 @@ let dominators_tarjan graph =
   ) graph;
 
   Util.Timer.start tjntimer;
-#if OCAMLGRAPHVERSION <= 186
-  let module Dom = Dominator.Make_graph(G) in
-#else
   let module Dom = Dominator.Make(G) in
-#endif
   let idom = Dom.compute_all graph start_pkg in
   let domgr = idom.Dom.dom_graph () in
   Util.Timer.stop tjntimer ();
diff --git a/common/criteria_lexer.mll b/common/criteria_lexer.mll
index 5518fa0..33c57bc 100644
--- a/common/criteria_lexer.mll
+++ b/common/criteria_lexer.mll
@@ -13,6 +13,11 @@
 {
   open Criteria_parser
 
+  module Bytes = struct
+include String
+let sub_string = String.sub
+  end
+
   let get_regexp lexbuf =
 let open Lexing in
 let c = Lexing.lexeme_char lexbuf 2 in (* the delimiter can be any 
character *)
diff --git a/myocamlbuild.ml.pp b/myocamlbuild.ml.pp
index e0283cc..60f6fcd 100644
--- a/myocamlbuild.ml.pp
+++ b/myocamlbuild.ml.pp
@@ -2,11 +2,6 @@
 open Ocamlbuild_plugin;;
 
 Options.use_ocamlfind := true ;;
-#if OCAML_VERSION > (4, 1, 0)
-Ocamlbuild_pack.Flags.mark_tag_used "use_" ;;
-Ocamlbuild_pack.Flags.mark_tag_used "pkg_" ;;
-Ocamlbuild_pack.Flags.mark_tag_used "link_" ;;
-#endif
 
 let modules_dirs = [
   "common"; "versioning"; "pef"; "opam"; "deb"; "opencsw"; "rpm"; "algo";

Bug#802264: src:matita: FTBFS with OCaml 4.02.3

[Mehdi Dogguy]

Hi Enrico,

On 20/01/2016 11:15, Enrico Tassi wrote:
> On Sun, Oct 18, 2015 at 11:03:35PM +0200, Mehdi Dogguy wrote:
>> Package: src:matita
>> Version: 0.99.1-3
>> Severity: serious
>>
>> Dear Maintainer,
> 
> This bugs is due to camlp5 and fixed in
> caca3dd0643ec5aae9df4399fa73eb280808ef18
> 
> see https://gforge.inria.fr/projects/camlp5/
> 

Even using that fix, I get the following failure (while building matita):

  OCAMLC hExtlib.ml
File "hExtlib.ml", line 463, characters 10-23:
Warning 3: deprecated: String.create
Use Bytes.create instead.
File "hExtlib.ml", line 1:
Error: The implementation hExtlib.ml
   does not match the interface hExtlib.cmi:
   Values do not match:
 val find : ?test:(string -> bool) -> string -> string list
   is not included in
 val find : ?test: -> string -> string list
   File "hExtlib.ml", line 530, characters 4-8: Actual declaration
../Makefile.common:99: recipe for target 'hExtlib.cmo' failed
make: *** [hExtlib.cmo] Error 2

Didn't you get that error?

-- 
Mehdi

Bug#811248: Error in manpage: --arch should be --deb-native-arch

[Mehdi Dogguy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: tags 811248 + fixed-upstream

Hi,

On 17/01/2016 09:52, Christoph Berg wrote:
> Package: dose-builddebcheck
> Version: 4.0.2-2
> Severity: normal
> 
> Hi,
> 

Thanks for your bugreport!

> I'm just working on using the dose tools to test installability of the
> packages on apt.postgresql.org. This will prove very useful to track
> e.g. if I need to recompile something there because perl or python
> just changed sonames in sid. Thanks for this great tool suite!
> 
> Now for the bug: dose-builddebcheck(1), under EXAMPLES:
> 
> dose-builddebcheck -v -f -e --arch amd64 \
> 
> That should be --deb-native-arch=amd64.
> 
> Also, the manpage title is BUILDCHECK(1).
> 
> Thirdly, the manpage doesn't mention that dose-builddebcheck is able
> to read compressed Sources.gz files. That could maybe save some people
> some decompression shell scripts.
> 

It looks like this bug has been addressed by upstream recently. See:

https://scm.gforge.inria.fr/anonscm/gitweb?p=dose/dose.git;a=commitdiff;h=f2a78ea78f4dc3214c2b78b27cabed47f6c7f774

... and released in 4.2.

Please let us know if the fix addresses all your concerns or needs further
changes.

Regards,

- -- 
Mehdi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWnp5jAAoJEDO+GgqMLtj/wEIP/3j8IlGdOSQUeFpKECEY9Mph
HJ5RT5Lj7MrbtsDpQGGcY4bQCCwT5hqexpJunA3oVS737zdQA1KNkdv/uchPHUd8
ckKPE4fc3iH2M8RRPn2wRiat8y3GFOsv6SembfjoQ4BA9+fXWQe5x3k7r1AoDYjS
Aq8MFGCcUeWE7CMo9O8/uQP1aGAC5Wwshpuw7YvLpzVvb9f86L6WQuZqBqfzIo2h
7hxdgEXcvNLkChtJdHsjnJrVWAAKWAbVleYTAmo2h00tOE0dgMstFCpFPUoWlFc7
gTEp59SiHZNuEZP34o/vhF8PAfTOiiXYICSMMA93Z5DDNVrYxZZIOkyPTbRVx5Df
/8oB8UraUp+tIHBbCCeTlzkmDx6vxcEmxDNjX5wwAjB+T2aLbhupI7CSmUd7amUN
8MR1RDq/dqYQZiddgWavLI8WAr5uGtT9OAZmKMAqtM5fFwbF4YCiMxz6nWdJDXdL
WMsVE82jYsnvXWcjhekBKrzMnNcLOc7VtcmyPUZpqBXKYDnpOfLJAsQ14ONnMKxG
oGZszrjgXdc+xEPQvBT9Q6SVugD72wJ3jB5fPnKtd8aOAHlb6J2GIm0wna2wJAlT
Bk5kNDiapjdNJxbWaOpfovOXmPFikqLpkNpzvMqY3rkfNHvP+wdnubxIxqm6D2KP
erYAneSC6cINq4CO2wKu
=fqGv
-END PGP SIGNATURE-

Bug#810303: dose-builddebcheck output breaks backwards compatibility in 4.1 dropping the "src:" prefix, worth NEWS?

[Mehdi Dogguy]

Hi Pietro,

Thanks for the quick reply!

On 19/01/2016 23:41, Pietro Abate wrote:
> 
> This change was indeed intentional.

Thanks for the confirmation!

> 
> Mehdi, where are these places in the code that still expect "src:" ?
> I've removed this prefix from all the yaml output. I didn't really
> check if some input require the package to be prefixed with "src:",
> but it shouldn't be...
> 

Only did a quick grep:

% git grep -n "\"src:" **/*.ml
applications/deb-buildcheck.ml:182:  let (name,filter) = 
Debian.Debutil.debvpkg to_cudf (("src:"^n,a),c) in
deb/debcudf.ml:343:if String.starts_with pkg#name "src:" then
deb/sources.ml:235:  let sn = CudfAdd.encode ("src:"^(CudfAdd.get_property 
"source" binpkg)) in
deb/tests.ml:875:  "any/native", "src:source1", returns [
deb/tests.ml:883:  "stage1", "src:source2", returns [
deb/tests.ml:892:  "indep", "src:source3", returns [

Are those occurences expected?

> For this release, I also re-wrote the yaml printer from scratch and
> there might still be a few problems here and there... In particular
> dependency chains, when there is more then one path from a package to
> a dependency problem (missing package or conflict), are not all
> explicitly printed/expanded as before. Instead I just print one path.
> 
> Please let me know how I can help. This tool is for the debian
> community :) I'll be at fosdem at the end of the month, if you want to
> have a face to face chat.
> 
> p
> 

-- 
M.

Bug#810303: dose-builddebcheck output breaks backwards compatibility in 4.1 dropping the "src:" prefix, worth NEWS?

[Mehdi Dogguy]

Hi,

On 08/01/2016 06:24, Helmut Grohne wrote:
> Package: dose-builddebcheck
> Version: 4.1-1
> File: /usr/bin/dose-builddebcheck
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> Hi,
> 
> I am one of the active consumers of dose-builddebcheck in unstable and
> quickly noticed the 4.1 upload by seeing all rebootstrap jobs fail. The
> immediate reason is that dose was formerly tagging source packages with
> a "src:" prefix and now no longer does so. I quickly updated the
> consumer code, but Johannes asked me to file a bug nonetheless.
> 

Good catch. I /think/ that this change is not intended and is a bug since
some places in the code still expect the "src:" prefix to be there somehow.

Since printers have been reworked in 4.1, I'd think this is a bug introduced
in 4.1 and still not fixed in recently released 4.2. I'd appreciate a
confirmation by upstream though.

@Pietro: Can you please enlighten us on this issue?

Regards,

-- 
Mehdi

Bug#790422: Parsing.Parse_error

[Mehdi Dogguy]

Hi,

On 19/01/2016 23:07, Christoph Berg wrote:
> 
> Long story, but that's the real-world example here. In fact I'm
> considering upgrading the apt.pg.o build host to stretch just because
> of this bugfix, and because a backport of the current dose-debcheck
> version to jessie looks too hard.
> 

After seeing your message, I was curious and tried to backport it. I still
didn't get it to compile because of some weird OCaml feature but I think
all what is left to do is to backport extlib (which is easy).

See file attached. Changes in "applications/distcheck.ml" should not be
kept. That's the part that will require a newer Extlib if a workaround cannot
be found.

Regards,

-- 
Mehdi
diff -ruNd dose3-4.1/myocamlbuild.ml.pp new/myocamlbuild.ml.pp
--- dose3-4.1/myocamlbuild.ml.pp	2016-01-04 12:53:12.0 +0100
+++ new/myocamlbuild.ml.pp	2016-01-20 01:12:10.231339730 +0100
@@ -2,11 +2,6 @@
 open Ocamlbuild_plugin;;
 
 Options.use_ocamlfind := true ;;
-#if OCAML_VERSION > (4, 1, 0)
-Ocamlbuild_pack.Flags.mark_tag_used "use_" ;;
-Ocamlbuild_pack.Flags.mark_tag_used "pkg_" ;;
-Ocamlbuild_pack.Flags.mark_tag_used "link_" ;;
-#endif
 
 let modules_dirs = [
   "common"; "versioning"; "pef"; "opam"; "deb"; "opencsw"; "rpm"; "algo";
diff -ruNd dose3-4.1/Makefile.config.in new/Makefile.config.in
--- dose3-4.1/Makefile.config.in	2016-01-04 12:53:12.0 +0100
+++ new/Makefile.config.in	2016-01-20 01:05:53.328459693 +0100
@@ -4,7 +4,8 @@
 CFLAGS=@CFLAGS@ -fPIC -Wall -pedantic -Werror -Wno-long-long -warn-error FPSXY
 CPPFLAGS=@CPPFLAGS@
 LDFLAGS=@LDFLAGS@
-CPPOFLAGS=-V OCAML:$(shell ocamlc -version)
+#CPPOFLAGS=-V OCAML:$(shell ocamlc -version)
+CPPOFLAGS=
 
 
 OCAMLFIND=@OCAMLFIND@
diff -ruNd dose3-4.1/algo/diagnostic.ml new/algo/diagnostic.ml
--- dose3-4.1/algo/diagnostic.ml	2016-01-04 12:53:12.0 +0100
+++ new/algo/diagnostic.ml	2016-01-20 00:28:32.881700239 +0100
@@ -525,8 +525,7 @@
   open Defaultgraphs.SyntacticDependencyGraph
   type label = G.E.label
   type t = int
-  type edge = G.E.t
-  let weight e = match G.E.label e with { contents = PkgE.Conflict _ } -> 1000 | _ -> 0
+  let weight e = match !e with PkgE.Conflict _ -> 1000 | _ -> 0 
   let compare = Pervasives.compare
   let add = (+)
   let zero = 0
diff -ruNd dose3-4.1/algo/dominators.ml new/algo/dominators.ml
--- dose3-4.1/algo/dominators.ml	2016-01-04 12:53:12.0 +0100
+++ new/algo/dominators.ml	2016-01-20 00:24:18.161312088 +0100
@@ -101,11 +105,11 @@
   ) graph;
 
   Util.Timer.start tjntimer;
-#if OCAMLGRAPHVERSION <= 186
-  let module Dom = Dominator.Make_graph(G) in
-#else
   let module Dom = Dominator.Make(G) in
-#endif
   let idom = Dom.compute_all graph start_pkg in
   let domgr = idom.Dom.dom_graph () in
   Util.Timer.stop tjntimer ();
diff -ruNd dose3-4.1/applications/distcheck.ml new/applications/distcheck.ml
--- dose3-4.1/applications/distcheck.ml	2016-01-04 12:53:12.0 +0100
+++ new/applications/distcheck.ml	2016-01-20 00:55:15.690760013 +0100
@@ -24,7 +24,7 @@
   open OptParse
   open OptParser
   let description = "Compute the list broken packages in a repository"
-  let options = OptParser.make ~description
+  let options ?usage:(usage="") ?status:(status=0) = OptParser.make ~usage ~description
   include StdOptions.MakeOptions(struct let options = options end)
 
   let coinst = StdDebian.vpkglist_option ();;
diff -ruNd dose3-4.1/common/criteria_lexer.mll new/common/criteria_lexer.mll
--- dose3-4.1/common/criteria_lexer.mll	2016-01-04 12:53:12.0 +0100
+++ new/common/criteria_lexer.mll	2016-01-20 00:20:49.609185831 +0100
@@ -13,6 +13,11 @@
 {
   open Criteria_parser
 
+  module Bytes = struct
+include String
+let sub_string = String.sub
+  end
+
   let get_regexp lexbuf =
 let open Lexing in
 let c = Lexing.lexeme_char lexbuf 2 in (* the delimiter can be any character *)

Bug#810303: dose-builddebcheck output breaks backwards compatibility in 4.1 dropping the "src:" prefix, worth NEWS?

[Mehdi Dogguy]

Hi

On 20/01/2016 01:10, Pietro Abate wrote:
> Hi
> 
> On 20/01/16 00:00, Mehdi Dogguy wrote:
>> Only did a quick grep:
>>
>> % git grep -n "\"src:" **/*.ml
>> applications/deb-buildcheck.ml:182:  let (name,filter) = 
>> Debian.Debutil.debvpkg to_cudf (("src:"^n,a),c) in
> 
> Here I append "src:" to the name of a debian package to find the
> corresponding cudf package
> 
>> deb/debcudf.ml:343:if String.starts_with pkg#name "src:" then
>> deb/sources.ml:235:  let sn = CudfAdd.encode ("src:"^(CudfAdd.get_property 
>> "source" binpkg)) in
> 
> These two are part of the debian <-> cudf encoding. The first one
> removes the "src:" prefix. The second one adds the prefix to the debian
> package.
> 
>> deb/tests.ml:875:  "any/native", "src:source1", returns [
>> deb/tests.ml:883:  "stage1", "src:source2", returns [
>> deb/tests.ml:892:  "indep", "src:source3", returns [
> And these are test cases...
> 
>> Are those occurences expected?
> 
> so, yes. These are all expected. The src: prefix is still used to
> encode source packages in cudf (and to differentiate to binary
> packages). The difference from the previous release is that this
> encoding is not visible anymore to the final user in the yaml report.
> 

Ah. Indeed. Thanks for the clear explanation! It all makes sense now :)

Cheers,

-- 
M

Bug#809225: Nice way to solve bugs and segfaults

[Mehdi Dogguy]

Bonjour,

On 11/01/2016 08:39, Nathael Pajani wrote:
> Hi !
> 
> What a nice way to resolve a bug or segfault. None of my students
> ever tried this one yet.
> 
> Should remember it next time someone requests tech support for one of
> my products.
> 

I am not sure this message helps anything in any way. I can certainly
understand your frustration. I am not convinced this reaction can make
things moving forward. Instead, let's focus on the core issue.

AFAIK, older versions of Unison cannot work with OCaml 4.02. The latter
has been uploaded last October and we've transitioned all the OCaml stack
to 4.02.3. Since we don't support multiple version of OCaml in the same
archive, older versions of Unison had to be removed since they became
useless. Stéphane could have invested some time to backport necessary
changes to make them work with OCaml 4.02.3. Unfortunately, this requires
quite some work and was not worth trying.

The remaining issue is the situation of users of mixed machines stable/testing.
We are working on a solution for them and we are quite confident to get this
sorted out. The solution will probably land debian-backports and will be
announced on this list. So stay tuned!

In the meantime, he are the few working solutions that have been mentioned
by some users:
1) Copy needed binaries on systems you want to synchronize with.
2) Install Unison's packages from Jessie, and not use Stretch's ones.

If you encountering an issue that is not covered by what I've described, please
do share it with us so that we can try to help you.

> 
> Have fun.
> 

Likewise.

Kind regards,

-- 
Mehdi

Bug#807019: unison2.40.102: Segmentation fault

[Mehdi Dogguy]

Hi,

On 10/01/2016 02:19, Ashley Hooper wrote:
> 
> Is there any reason the Jessie versions couldn't be retained in
> Stretch instead of the broken unison2.32.52 version?
> 

We do not support multiple OCaml versions in the archive. As long
as that holds true, Unison <2.48 won't work with OCaml >=4.02.3.
For now, we've requested the removal of Unison 2.40 and 2.32 from
Stretch and we are looking for a solution to make 2.48 also work
in stable.

Regards,

-- 
Mehdi

Bug#810531: RM: unison2.32.52 -- ROM; Broken (#809225)

[Mehdi Dogguy]

Package: ftp.debian.org
Severity: normal

Hi,

Unison 2.32 is broken now that we moved to OCaml 4.02.3 (See #809225).
Just like Unison 2.40, please remove it from the archive.

Regards,

--
Mehdi

Bug#807019: unison2.40.102: Segmentation fault

[Mehdi Dogguy]

Hello,

On 09/01/2016 03:31, Ashley Hooper wrote:
> Is it at all feasible to downgrade the installed version of ocaml
> 4.01.x on Stretch? I am reliant on Unison 2.32 (due to that being the
> most recent version available for another device I use).
> 
> I'm only seeing the 4.02 version available in the repos.
> 
> $ apt-cache madison ocaml ocaml |   4.02.3-5 |
> http://ftp.nz.debian.org/debian stretch/main amd64 Packages ocaml |
> 4.02.3-5 | http://ftp.nz.debian.org/debian stretch/main Sources
> 

Unfortunately, there is no plan to downgrade OCaml's version in Stretch.
If you need a working Unison setup across multiple systems based on different
versions, you may copy needed Unison binary around, for now.

Regards,

-- 
Mehdi

Bug#810212: segfaults when using as unison-2.40 to sync with a jessie system

[Mehdi Dogguy]

On 2016-01-08 11:28, Enrico Zini wrote:

On Thu, Jan 07, 2016 at 09:05:51PM +0100, Mehdi Dogguy wrote:


Indeed. You can also see #807019 for more information about this bug.
At this point, we are stuck with no real solution (except doing 
massive

backports). Some people copy over unison binary on Jessie systems to
be able sync, or install Jessie's unison on their testing or sid box.


Ack. Given the situation, could a new version of unison for stable be a
worthwile candidate for something to go in a point release?



AFAIK, this plan requires also a new version of OCaml stable which is a
no-go. That's I've mentioned the idea of backporting OCaml 4.02.3 and
use it to backport Unison 2.48. Possibly, Unison 2.48 in backports won't
have the gtk interface to reduce the number of packages to backport.

Regards,

--
Mehdi

Bug#810213: Ben: Use https instead of http for external links

[Mehdi Dogguy]

Source: ben
Version: 0.7.0

The documentation as well the templates contain http links. Those should 
use

https instead of http.

Bug#810212: segfaults when using as unison-2.40 to sync with a jessie system

[Mehdi Dogguy]

Hi Enrico,

On 07/01/2016 10:55, Enrico Zini wrote:
> Package: unison
> Version: 2.48.3-1
> Severity: important
> 
> Hello,
> 
> thank you for maintaining unison.
> 
> It seems unison is not able to sync to a jessie system anymore:
> 

Indeed. You can also see #807019 for more information about this bug.
At this point, we are stuck with no real solution (except doing massive
backports). Some people copy over unison binary on Jessie systems to
be able sync, or install Jessie's unison on their testing or sid box.

Regards,

-- 
Mehdi

Bug#810270: RM: unison2.40.102 -- ROM; Broken (#807019)

[Mehdi Dogguy]

Package: ftp.debian.org
Severity: normal

Hi,

Unison 2.40 is broken now that we moved to OCaml 4.02.3 (See #807019).
Please remove it from the archive. I've uploaded an updated meta-unison
package which removes the dependency on this package.

Regards,

--
Mehdi

Bug#639910: Packaging sbt

[Mehdi Dogguy]

Hi,

On 05/01/2016 16:32, Emmanuel Bourg wrote:
> The "easiest" solution is probably to start with a non-free sbt package
> containing a prebuilt version of sbt, and then upload in main a sbt
> package depending on itself with the prebuilt sbt removed. I would use
> only one sbt package, instead of sbt-bootstrap in non-free and sbt in main.
> 

Note that you can very much include a working sbt binary in the source
package and use it the bootstrap sbt. The only condition that we must
respect is to not ship that binary in the package, but ship the built
binary only. This is done for many packages: OCaml for its bootstrap
and most probably ghc (didn't check tbh). Also, compiling gcc requires
a gcc. :-P

My 2 cents,

-- 
Mehdi

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Mehdi Dogguy]

On 2016-01-03 07:35, Christian PERRIER wrote:

Quoting Philippe Cerfon (philc...@gmail.com):

Package: general
Severity: wishlist
Tags: security

Hi.

I think Debian has the following two problems (or rather its security
conscious users) with respect to software that gets into the system:



No idea whether what you're proposing is relevant or notbut
there's something I'm deeply sure of : that won't be solved through a
"general" bug report.

Such vague bug reports are usually either quickly closedor just
ignored by everybody in the project.



Well, the messages sent to this bugreport land in debian-devel, which
looks appropriate for this kind of discussions, IMHO. Be it a bugreport
or a simple message sent to the list, it doesn't look very different.

Once discussion happens and we have a clear idea on what is needed to
do, we will be able to describe a concrete plan or, aternatively, close
the bugreport because nothing is needed to do. The concrete plan could
be several bugreports files where appropriate, blocking this one.

We do already track discussions in bugreports (Tech-ctte issues for
example), even if the initial request might be very vague or quite
complicated.

Regards,

--
Mehdi

Bug#806129: jessie-pu: package augeas/1.2.0-0.2+deb8u1

[Mehdi Dogguy]

Hi,

On 04/01/2016 11:57, SOUBEYRAND Yann - externe wrote:
> 
> Thank you for the review of the package.
> 
> FYI I've open a RFS to find a sponsor for the upload
> (https://bugs.debian.org/809809).
> 

I've uploaded it.

Thanks for your contribution!

Regards,

-- 
Mehdi

Bug#807019: tracking bin-num - broken unison due to binnmu upload

[Mehdi Dogguy]

On 2016-01-04 17:24, Stéphane Glondu wrote:

Le 22/12/2015 00:38, Mehdi Dogguy a écrit :
The change done in unison 2.48 to overcome this looks pretty big... 
I'm

not sure I'll be able/willing to provide a unison2.40.102 any more.
Moreover, this package was created to provide compatibility with
previous Debian releases, but another change in OCaml 4.02 makes it
incompatible anyway (both communicating unisons need to be compiled 
with
the same version of OCaml in practice, which won't be the case any 
more

when one side is Debian stable, and the other Debian testing). IMHO,
that's a design flaw in Unison that cannot be easily fixed.



A possible way out for stable (and old-stable) users could be to use 
2.48

from backports, when 2.48 will be packaged and migrated to testing.


No, 2.48 from backports will be compiled with stable's version of OCaml
(4.01.0) whereas 2.48 from testing will (eventually) be compiled with
testing's version of OCaml (4.02.3), making both versions incompatible.



Oh, my understanding was that newer versions of Unison were not bound on
an OCaml version anymore and have had worked a synchronization format 
which

will work well with any OCaml version. Sorry if this is not the case.


Personally, what I do when dealing with inter-release synchronization
involves using schroot... I heard of people copying binaries around, 
and

others recompiling unison locally on one system. I don't know which
solution is the best. The situation sucks.



It is possible to backport OCaml 4.02.3 (and lablgtk2 :-/) and use that
from backports to build a compatible version of Unison. I realize this 
is

a lot of work though.

Regards,

--
Mehdi

Bug#803887: info ocaml fails

[Mehdi Dogguy]

Hi,

On 02/11/2015 23:01, Sebastien Hinderer wrote:
> Package: ocaml-doc
> Version: 4.02-1
> Severity: normal
> 
> The ocaml programming manual node is listed in the dir node but it is
> not possible to open it.
> 
> The status line says:
> 
> Cannot find node ''.
> 
> When the package is installed, one can see:
> 
> install-info: warning: no info dir entry in
> `/usr/share/info/ocaml.info.haux.gz'
> install-info: warning: no info dir entry in
> `/usr/share/info/ocaml.info.hocaml.info.hind.gz'
> install-info: warning: no info dir entry in
> `/usr/share/info/ocaml.info.body.gz'
> install-info: warning: no info dir entry in
> `/usr/share/info/ocaml.info.hocaml.info.kwd.hind.gz'
> 

Since the original issue has been fixed in install-info, the only action
left is about removing ocaml.info.body.gz file from shipped files.

Next upload will fix that.

Regards,

-- 
Mehdi

Bug#805456: unison: works well on my testing

[Mehdi Dogguy]

Control: tags 805456 = moreinfo unreproducible
Control: severity 805456 important

Indeed. Works for me too. I am downgrading the severity of this bug and
tagging it as "unreproducible", waiting for a reaction by the submitter.

-- 
Mehdi

Bug#802166: otags: fails to install: post-installation script returned error exit status 3

[Mehdi Dogguy]

Hello,

On 29/12/2015 12:44, Hendrik Tews wrote:
> Mehdi Dogguy <me...@dogguy.org> writes:
> 
>> Can you give us a hint on how to work out a real fix for this issue?
> 
> I am looking at it now. There is quite a bit new syntax in 4.02,
> yielding quite a few warnings about incomplete pattern in otags.
> Each of these will crash otags in the same way, for instance
> attributes, extension nodes, extensible variant types.
> 

Sure.

> I try to make a new release, but it will take more than one day.
> 

Ok. Thanks for the heads up. I'll make a new Debian release to avoid
crashes and will wait until new release comes out to close this bug.


... and thanks for maintaining otags!

Cheers.

-- Mehdi

Bug#807019: tracking bin-num - broken unison due to binnmu upload

[Mehdi Dogguy]

Hi,

On 29/12/2015 11:13, Alexander Wirt wrote:
> On Tue, 29 Dec 2015, Alexandre Rossi wrote:
> 
>> Hi,
>> 
 The change done in unison 2.48 to overcome this looks pretty
 big... I'm not sure I'll be able/willing to provide a
 unison2.40.102 any more. Moreover, this package was created to
 provide compatibility with previous Debian releases, but
 another change in OCaml 4.02 makes it incompatible anyway (both
 communicating unisons need to be compiled with the same version
 of OCaml in practice, which won't be the case any more when one
 side is Debian stable, and the other Debian testing). IMHO, 
 that's a design flaw in Unison that cannot be easily fixed.
 
>>> 
>>> A possible way out for stable (and old-stable) users could be to
>>> use 2.48 from backports, when 2.48 will be packaged and migrated
>>> to testing.
>> 
>> The backport is indeed a nice way out of this, the rebuild is 
>> straightforward (only tried for amd64). 
>> http://sousmonlit.zincube.net/~niol/apt/pool/main/u/unison/unison_2.48.3-1~bpo80+1.dsc
>>
>>
>> 
This should be integrated in the backports.d.o repositories.
> Backports is not for fixing bugs in stable.
> 

Should the description from backports.d.o be adjusted then? For now, it reads:

  Backports are packages taken from the next Debian release (called "testing"),
  adjusted and recompiled for usage on Debian stable.

Alternatively, can you please explain how this case doesn't fit?

We didn't need to backport Unison in the past because it used to work well
even with different OCaml versions. Now, this changed in 2.48 and we are not
able to offer sync between Stable and Testing machines anymore. In fact, the
"issue" was triggered by the fact that some internal structures changed in
some OCaml modules rendering Unison <2.48 unusable with recent OCaml version.
This is now fixed in Unison 2.48... hence the backport of Unison 2.48. But
there is nothing to fix in Stable...

My only doubt right now (about the backport) is about #805456. It would
be great to hear about the submitter before exposing Unison 2.48 to users
of stable.

Regards,

-- Mehdi