Bug#972262: marked as pending in ocamlviz

[Mehdi Dogguy]

Control: tag -1 pending

Hello,

Bug #972262 in ocamlviz reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ocaml-team/ocamlviz/-/commit/d2a599e56e82e14a1284fbb6c5e2a7b7886ae9eb


Fix FTBFS by using Bytes where necessary (Closes: #972262)

- Remove 0003-Compile-with-unsafe-string-for-now.patch, which is
  not needed anymore
- Add 0003-Use-Bytes-only-where-necessary.patch


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/972262

Bug#980309: marked as pending in opam

[Mehdi Dogguy]

Control: tag -1 pending

Hello,

Bug #980309 in opam reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ocaml-team/opam/-/commit/c6686267c0a384112dfa7b0c406c0f6f7d1b5460


Move documentation files back in opam-installer and update needed 
Breaks/Replaces in opam-installer's stanza (Closes: #980309)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/980309

Bug#897774: Bug #897774 in infinipath-psm marked as pending

[Mehdi Dogguy]

Control: tag -1 pending

Hello,

Bug #897774 in infinipath-psm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/hpc-team/infinipath-psm/commit/c5a458aa4ebfe64fa7f3f911f3dbd0a74bf3c8ec


Fix ftbfs with GCC-8 (Closes: #897774)



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/897774

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#909086: Bug #909086 in opam marked as pending

[Mehdi Dogguy]

Control: tag -1 pending

Hello,

Bug #909086 in opam reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/ocaml-team/opam/commit/8fa9d29ba36d98f349516f0101a5593fbbe51a05


Add a strict dependency on bubblewrap (Closes: #909086)



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/909086

Bug#907431: Bug #907431 in cppo marked as pending

[Mehdi Dogguy]

Control: tag -1 pending

Hello,

Bug #907431 in cppo reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/ocaml-team/cppo/commit/416abc291f17f06e40d0bbc9e2d3cd6ba20e265c


Fix issue on arm{el,hf} and ppc64el (Closes: #907431)



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/907431

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#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#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#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#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#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#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#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#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#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#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#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#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#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

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#802166: otags: fails to install: post-installation script returned error exit status 3

[Mehdi Dogguy]

Hi Hendrik,

On 08/11/2015 20:58, Hendrik Tews wrote:
> Hi,
> 
> it's a pattern matching failure in tag_module_type, which means
> the file stdLabels.mli contains some module type that I didn't
> know about when I wrote tag_module_type.
> 
> As a quick solution you can add a catch-all line
> 
>| _ -> ()
> 
> to tag_module_type. This will hopefully fix the bug, but you
> won't get tags for the offending module type.
> 

I have to admit that I am not a big fan of camlp4 and I guess we
don't want to go with the catch-all workaround since it introduces
a new bug in otags. The function to fix is:

   
http://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/otags.git/tree/tags.ml#n361

Can you give us a hint on how to work out a real fix for this issue?
Or, do you plan to release a new version of otags fixing this?

Regards,

-- 
Mehdi

Bug#802865: nss-passwords: FTBFS: ocaml/caml/config.h: error: conflicting types for 'int64'

[Mehdi Dogguy]

Hi,

The cause of this build failure may be fixed in OCaml 4.03 according to:

http://caml.inria.fr/mantis/view.php?id=6517

-- 
Mehdi

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

[Mehdi Dogguy]

Hi,

On 07/12/2015 16:23, Stéphane Glondu wrote:
> 
> 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.

My 2 cents,

-- 
Mehdi

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

[Mehdi Dogguy]

Package: src:matita
Version: 0.99.1-3
Severity: serious

Dear Maintainer,

Your package fails to build from source. Here is an excerpt from the 
build

log:

  OCAMLOPT nCic.ml
File "nCic.ml", line 142, characters 11-460:
Error: This class type should be virtual.
   The following variables are undefined : ppterm ppsubst ppobj
 ppmetasenv ppcontext
../Makefile.common:102: recipe for target 'nCic.cmx' failed
make[3]: *** [nCic.cmx] Error 2

A full build log is attached.

Regards,

--
Mehdi -> Copying COW directory
  forking: rm -rf /var/cache/pbuilder/build//cow.12549 
  forking: cp -al /var/cache/pbuilder/cows/unstable-amd64/ 
/var/cache/pbuilder/build//cow.12549 
I: removed stale ilistfile /var/cache/pbuilder/build//cow.12549/.ilist
  forking: chroot /var/cache/pbuilder/build//cow.12549 cowdancer-ilistcreate 
/.ilist find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a 
-links +1 -print0 \) | xargs -0 stat --format '%d %i ' 
 -> Invoking pbuilder
  forking: pbuilder build --buildplace /var/cache/pbuilder/build//cow.12549 
--buildresult /var/cache/pbuilder/result/unstable-amd64 --debbuildopts  
--no-targz --internal-chrootexec chroot /var/cache/pbuilder/build//cow.12549 
cow-shell /tmp/tmp.xoIxvDvlsS/matita_0.99.1-3.dsc 
I: Running in no-targz mode
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Sun Oct 18 22:53:33 CEST 2015
I: pbuilder-time-stamp: 1445201613
I: copying local configuration
I: mounting /proc 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.12549/tmp/hooks/D10aptupdate 
starting
Get:1 http://incoming.debian.org buildd-unstable InRelease [111 kB]
Get:2 http://incoming.debian.org buildd-unstable/main amd64 Packages [128 kB]
Get:3 http://http.debian.net unstable InRelease [250 kB]
Get:4 http://incoming.debian.org buildd-unstable/contrib amd64 Packages [500 B]
Get:5 http://incoming.debian.org buildd-unstable/non-free amd64 Packages [1828 
B]
Get:6 http://incoming.debian.org buildd-unstable/contrib Translation-en [402 B]
Get:7 http://incoming.debian.org buildd-unstable/main Translation-en [109 kB]   

Get:8 http://http.debian.net unstable/main amd64 Packages/DiffIndex [7876 B] 
Get:9 http://incoming.debian.org buildd-unstable/non-free Translation-en [2546 
B]
Get:10 http://http.debian.net unstable/main Translation-en/DiffIndex [7876 B]   
   
Get:11 http://http.debian.net unstable/main amd64 2015-10-18-1440.19.pdiff 
[13.4 kB]
Get:12 http://http.debian.net unstable/main amd64 2015-10-18-1440.19.pdiff 
[13.4 kB]
Get:13 http://http.debian.net unstable/main 2015-10-18-1440.19.pdiff [2025 B]
Get:14 http://http.debian.net unstable/main 2015-10-18-1440.19.pdiff [2025 B]
Fetched 635 kB in 3s (191 kB/s)  
Reading package lists... Done
I: user script /var/cache/pbuilder/build/cow.12549/tmp/hooks/D10aptupdate 
finished
I: user script /var/cache/pbuilder/build/cow.12549/tmp/hooks/D11unsafeio 
starting
Setting force-unsafe-io for dpkg
I: user script /var/cache/pbuilder/build/cow.12549/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 
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: ocaml (>= 3.10.2), ocaml-findlib (>= 1.2.1-2), libgdome2-ocaml-dev, 
liblablgtk2-ocaml-dev, libocamlnet-ocaml-dev, libzip-ocaml-dev, 
libhttp-ocaml-dev, ocaml-ulex08 (>= 0.8-4), libexpat-ocaml-dev, debhelper (>= 
8), camlp5 (>= 5.04), liblablgtksourceview2-ocaml-dev, autoconf, help2man
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 12072 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 ocaml (>= 3.10.2); however:
  Package ocaml is not installed.
 pbuilder-satisfydepends-dummy depends on ocaml-findlib (>= 1.2.1-2); however:
  Package ocaml-findlib is not installed.
 pbuilder-satisfydepends-dummy depends on libgdome2-ocaml-dev; however:
  Package libgdome2-ocaml-dev is 

Bug#802265: src:botch: FTBFS: target 'test-selfcontained' failed

[Mehdi Dogguy]

Package: src:botch
Version: 0.16-2
Severity: serious

Dear Maintainer,

Your package fails to build from source. Here is an excerpt from the 
build

log:

-Provides: myspell-dictionary, myspell-dictionary-en, 
myspell-dictionary-en-za

-Depends: dictionaries-common (>= 0.10) | openoffice.org-updatedicts
-Conflicts: openoffice.org (<= 1.0.3-2)
+Source: norwegian
+Provides: myspell-dictionary, myspell-dictionary-nn, 
openoffice.org-spellcheck-nn

+Depends: dictionaries-common (>> 0.10) | openoffice.org-updatedicts

 Package: mysql-common
 Version: 5.5.33+dfsg-1
Makefile:159: recipe for target 'test-selfcontained' failed
make[1]: *** [test-selfcontained] Error 1
make[1]: Leaving directory '/«PKGBUILDDIR»'
dh_auto_test: make -j1 test returned exit code 2
debian/rules:6: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2

Full build logs can be found here:

https://buildd.debian.org/status/package.php?p=botch=unstable

Regards,

--
Mehdi

Bug#802268: src:cduce: FTBFS with OCaml 4.02.3

[Mehdi Dogguy]

... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 17576 files and directories currently installed.)
Preparing to unpack .../libfakeroot_1.20.2-1_amd64.deb ...
Unpacking libfakeroot:amd64 (1.20.2-1) ...
Selecting previously unselected package fakeroot.
Preparing to unpack .../fakeroot_1.20.2-1_amd64.deb ...
Unpacking fakeroot (1.20.2-1) ...
Processing triggers for man-db (2.7.4-1) ...
Not building database; man-db/auto-update is not 'true'.
Setting up libfakeroot:amd64 (1.20.2-1) ...
Setting up fakeroot (1.20.2-1) ...
update-alternatives: using /usr/bin/fakeroot-sysv to provide /usr/bin/fakeroot 
(fakeroot) in auto mode
I: Copying back the cached apt archive contents
I: Copying source file
I: copying [/home/incoming/cduce_0.6.0-2.dsc]
I: copying [/home/incoming/cduce_0.6.0.orig.tar.gz]
I: copying [/home/incoming/cduce_0.6.0-2.debian.tar.xz]
I: Extracting source
gpgv: keyblock resource `/tmp/buildd/.gnupg/trustedkeys.gpg': file open error
gpgv: Signature made Sun Oct 18 21:08:23 2015 UTC using RSA key ID 8C2ED8FF
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./cduce_0.6.0-2.dsc
dpkg-source: info: extracting cduce in cduce-0.6.0
dpkg-source: info: unpacking cduce_0.6.0.orig.tar.gz
dpkg-source: info: unpacking cduce_0.6.0-2.debian.tar.xz
I: Building the package
I: user script /home/incoming/unstable/build/cow.24378/tmp/hooks/A00iptables 
starting
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
  libnfnetlink0 libxtables10
The following NEW packages will be installed:
  iptables libnfnetlink0 libxtables10
debconf: delaying package configuration, since apt-utils is not installed
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/358 kB of archives.
After this operation, 3818 kB of additional disk space will be used.
Selecting previously unselected package libnfnetlink0:amd64.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 17624 files and directories currently installed.)
Preparing to unpack .../libnfnetlink0_1.0.1-3_amd64.deb ...
Unpacking libnfnetlink0:amd64 (1.0.1-3) ...
Selecting previously unselected package libxtables10.
Preparing to unpack .../libxtables10_1.4.21-2+b1_amd64.deb ...
Unpacking libxtables10 (1.4.21-2+b1) ...
Selecting previously unselected package iptables.
Preparing to unpack .../iptables_1.4.21-2+b1_amd64.deb ...
Unpacking iptables (1.4.21-2+b1) ...
Processing triggers for man-db (2.7.4-1) ...
Not building database; man-db/auto-update is not 'true'.
Setting up libnfnetlink0:amd64 (1.0.1-3) ...
Setting up libxtables10 (1.4.21-2+b1) ...
Setting up iptables (1.4.21-2+b1) ...
Processing triggers for libc-bin (2.19-22) ...
Chain OUTPUT (policy ACCEPT)
target prot opt source   destination 
REJECT all  -- !127.0.0.1   !127.0.0.1owner GID match 
1234 reject-with icmp-port-unreachable
I: user script /home/incoming/unstable/build/cow.24378/tmp/hooks/A00iptables 
finished
I: Running cd tmp/buildd/*/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" 
dpkg-buildpackage -us -uc   -v0.6.0-2~ -Zxz   -v0.6.0-2~ -Zxz  -rfakeroot
dpkg-buildpackage: source package cduce
dpkg-buildpackage: source version 0.6.0-2
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Mehdi Dogguy <me...@debian.org>
 dpkg-source -Zxz -Zxz --before-build cduce-0.6.0
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
dh --with ocaml clean
   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/tmp/buildd/cduce-0.6.0'
touch Makefile.conf
[ ! -f Makefile ] || /usr/bin/make "NATIVE=true" clean
make[2]: Entering directory '/tmp/buildd/cduce-0.6.0'
for i in misc parser schema typing types compile runtime driver query 
ocamliface win32 tools tests; do \
(cd $i; rm -f *.cmi *.cmo *.cma *.cmx *.o *.a *.cmxa *~); \
done
(cd ocamliface; /usr/bin/make clean)
ma

Bug#797448: dose3 is unfit for transitioning to testing

[Mehdi Dogguy]

Control: reopen -1

Hi,

On Sun, Aug 30, 2015 at 09:10:02PM +0200, Johannes Schauer <jo...@debian.org> 
wrote:
>  - dose-builddebcheck changed some command line arguments but:
> * there is no NEWS.Debian informing users about this change
> * the exit code for wrong command line arguments is wrong (should be
>   greater or equal to 64) - this requires an upload of extlib 1.7.0
>  - the META file shipped by libdose-ocaml-dev omits the new Versioning
>module and thus breaks all software build depending on any dose3 module
> 

These are not the only issues with the current dose3. Here is what I noticed
while trying to port Opam to dose3 (= 4.0.1):

- Simply loading dose3 in an ocaml toplevel fails. This is because it tries
  to load debian.cma by default, which depends on versioning.cma. Users will
  see the following error:

  File "_none_", line 1:
  Error: Error while linking /usr/lib/ocaml/dose3/debian.cma(Debian):
  Reference to undefined global `Versioning'

  To make this work, I've removed "debian.cm*" from archive(byte) and
  archive(native).

- dose3.opam is present in META file, but opam.cma (and others) are missing.
  This doesn't seem to be a regression though.

Regards,

-- 
Mehdi Dogguy

Bug#791326: wfmath: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:14:55PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

Uses of std::string are exposed in the public API. A proposed patch is available
from:

https://launchpad.net/ubuntu/+source/wfmath/1.0.2+dfsg1-0.3ubuntu1

Regards,

-- 
Mehdi Dogguy

Bug#791316: yaml-cpp0.3: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:15:04PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

This package is affected just like src:yaml-cpp. A proposed patch is
available from:

https://launchpad.net/ubuntu/+source/yaml-cpp0.3/0.3.0-1.1ubuntu1

Regards,

-- 
Mehdi Dogguy

Bug#791267: relion: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:13:59PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

std::string used in multiple places, exposed in the public API. This, this 
packge
needs renaming. A proposed patch is available from:

   https://launchpad.net/ubuntu/+source/relion/1.3+dfsg-2ubuntu1

Regards,

-- 
Mehdi Dogguy

Bug#791330: usbprog: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:14:46PM +, Matthias Klose d...@debian.org 
wrote:
  - Rebuild the library using g++/g++-5 from experimental. Note that
most likely all C++ libraries within the build dependencies need
a rebuild too. You can find the log for a rebuild in
  https://people.debian.org/~doko/logs/gcc5-20150701/
Search for BEGIN GCC CXX11 in the log.
 
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

Renaming is needed since std::string is used and exposed in public API.

A proposed patch is available from:

   https://launchpad.net/ubuntu/+source/usbprog/0.2.0-2.1ubuntu1

Regards,

-- 
Mehdi Dogguy

Bug#791097: libbpp-qt: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:10:59PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

std:string exposed in public API. Packages needs a renaming.

Regards,

-- 
Mehdi Dogguy

Bug#791228: openlayer: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:13:18PM +, Matthias Klose d...@debian.org 
wrote:
  - Rebuild the library using g++/g++-5 from experimental. Note that
most likely all C++ libraries within the build dependencies need
a rebuild too. You can find the log for a rebuild in
  https://people.debian.org/~doko/logs/gcc5-20150701/
Search for BEGIN GCC CXX11 in the log.
 
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

std::string is used and exposed in public API. A proposed patch is available
from:

https://launchpad.net/ubuntu/+source/openlayer/2.1-1ubuntu1

Regards,

-- 
Mehdi Dogguy

Bug#791276: shiboken: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:14:09PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

Exposes a use of std::string in public API. A proposed patch is available
from:

https://launchpad.net/ubuntu/+source/shiboken/1.2.2-1ubuntu3

Regards,

-- 
Mehdi Dogguy

Bug#791273: scalc: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:14:06PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

Exposes std::string in the public API. A proposed patch is available from:

   https://launchpad.net/ubuntu/+source/scalc/0.2.4-4ubuntu1
   http://ubuntudiff.debian.net/q/package/scalc

Regards,

-- 
Mehdi Dogguy

Bug#791055: gnome-chemistry-utils: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:10:14PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

libgcu0 has no reverse dependencies except other binary packages from
the same source package. Unfortunately, binNMU'ing this package would
be useless because dependencies look like libgcu0 (= 0.14), libgcu0
( 0.15). I'd be interested to know why this isn't libgcu0
(= ${binary:Version}) though.

In any case, there are some uses of std::string exposed in the public
API. So this package needs fixing.

Regards,

-- 
Mehdi Dogguy

Bug#791283: siscone: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:14:17PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

This library uses std::list and std::string in its public API. A proposed patch
is available from:

https://launchpad.net/ubuntu/+source/siscone/2.0.6-1ubuntu1
http://ubuntudiff.debian.net/q/package/siscone

Regards,

-- 
Mehdi Dogguy

Bug#791310: vtk: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:14:54PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

There is an msg of type std::string exposed publicly in a class which is part
of the API. So vtk will need a rename. The version in experimental already 
bumped
from 8 to 10 though, but I don't think we should mix the two transitions 
together.

Regards,

-- 
Mehdi Dogguy

Bug#791232: openvrml: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:13:22PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

There are some std::string exposed in the public API.

  - If there are no reverse dependencies, it should be the package
maintainers decision if a transition is needed.  However this might
break software which is not in the Debian archive, and built
against these packages.
 

It seems that there are no reverse dependencies.

-- 
Mehdi Dogguy

Bug#791230: openrpt: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:13:20PM +, Matthias Klose d...@debian.org 
wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

It even has std::liststd::string exposed in the public API. So it definitely
needs renaming libopenrpt1. A proposed patch is available from:

   https://launchpad.net/ubuntu/+source/openrpt/3.3.7-1ubuntu1

Regards,

-- 
Mehdi Dogguy

Bug#791235: pajeng: library transition may be needed when GCC 5 is the default

[Mehdi Dogguy]

Control: tags -1 + confirmed
Control: severity -1 serious

On Fri, Jul 03, 2015 at 01:13:25PM +, Matthias Klose d...@debian.org 
wrote:
  - Rebuild the library using g++/g++-5 from experimental. Note that
most likely all C++ libraries within the build dependencies need
a rebuild too. You can find the log for a rebuild in
  https://people.debian.org/~doko/logs/gcc5-20150701/
Search for BEGIN GCC CXX11 in the log.
 
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.
 

Affected. Renaming is necessary. A proposed patch is available from:

   
https://launchpad.net/ubuntu/+source/pajeng/1.1+git20140604.1d5509f042-2ubuntu2

1.1+git20140604.1d5509f042-2ubuntu1 introduced the changes required
to rename binary packages, and 1.1+git20140604.1d5509f042-2ubuntu2
fixes a build issue with boost.

  - If there are no reverse dependencies, it should be the package
maintainers decision if a transition is needed.  However this might
break software which is not in the Debian archive, and built
against these packages.
 

It has only one reverse dependency (viva) which has low popcon.

Regards,

-- 
Mehdi Dogguy

Bug#777776: apron: ftbfs with GCC-5

[Mehdi Dogguy]

Control: severity -1 normal

Le 2015-07-19 16:23, gregor herrmann a écrit :


Builds fine for me in an amd64 unstable + g++-from-experimental
cowbuilder chroot.



Same here. Attached a buildlog (tested with g++ 5_5.2.1-11 from exp).
I am adjusting the bug's severity accordingly, but not closing it for
now.

Regards,

--
Mehdidpkg-buildpackage: source package apron
dpkg-buildpackage: source version 0.9.10-6
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Stéphane Glondu glo...@debian.org
dpkg-buildpackage: host architecture amd64
dh clean --with ocaml
   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/tmp/buildd/apron-0.9.10'
[ ! -f /tmp/buildd/apron-0.9.10/Makefile ] || [ ! -f 
/tmp/buildd/apron-0.9.10/Makefile.config ] || /usr/bin/make clean
make[1]: Leaving directory '/tmp/buildd/apron-0.9.10'
   dh_ocamlclean
   dh_clean
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building apron using existing ./apron_0.9.10.orig.tar.gz
dpkg-source: info: building apron in apron_0.9.10-6.debian.tar.xz
dpkg-source: info: building apron in apron_0.9.10-6.dsc
dh build --with ocaml
   dh_testdir
   dh_ocamlinit
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/tmp/buildd/apron-0.9.10'
cp debian/Makefile.config .
mkdir -p /tmp/buildd/apron-0.9.10/debian/tmp/usr/include
echo APRON_PREFIX = /tmp/buildd/apron-0.9.10/debian/tmp/usr  Makefile.config
echo MLGMPIDL_PREFIX = /tmp/buildd/apron-0.9.10/debian/tmp/usr  
Makefile.config
echo OPT=.opt  Makefile.config
echo OCAML_BEST=opt  Makefile.config
make[1]: Leaving directory '/tmp/buildd/apron-0.9.10'
   debian/rules override_dh_auto_build
make[1]: Entering directory '/tmp/buildd/apron-0.9.10'
/usr/bin/make
make[2]: Entering directory '/tmp/buildd/apron-0.9.10'
sed  -e '1 aHAS_MPFR=1\n' Makefile.config mlgmpidl/Makefile.config
cp -f Makefile.config apron/Makefile.config
(cd mlgmpidl; make all install)
make[3]: Entering directory '/tmp/buildd/apron-0.9.10/mlgmpidl'
/usr/bin/ocamlc.opt -g  -c mpz.mli
/usr/bin/ocamlc.opt -g  -c mpzf.mli
/usr/bin/ocamlc.opt -g  -c mpq.mli
/usr/bin/ocamlc.opt -g  -c mpqf.mli
/usr/bin/ocamlc.opt -g  -c mpf.mli
/usr/bin/ocamlc.opt -g  -c mpfr.mli
/usr/bin/ocamlc.opt -g  -c mpfrf.mli
/usr/bin/ocamlc.opt -g  -c gmp_random.mli
/usr/bin/ocamlc.opt -g  -c mpz.ml
/usr/bin/ocamlc.opt -g  -c mpzf.ml
/usr/bin/ocamlc.opt -g  -c mpq.ml
/usr/bin/ocamlc.opt -g  -c mpqf.ml
/usr/bin/ocamlc.opt -g  -c mpf.ml
/usr/bin/ocamlc.opt -g  -c mpfr.ml
/usr/bin/ocamlc.opt -g  -c mpfrf.ml
/usr/bin/ocamlc.opt -g  -c gmp_random.ml
gcc -Wcast-qual -Wswitch -Werror-implicit-function-declaration -Wall -Wextra 
-Wundef -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wno-unused 
-std=c99 -U__STRICT_ANSI__ -fPIC -O3 -DNDEBUG -DHAS_MPFR=1 -I/usr/include 
-I/usr/include -I/usr/lib/ocaml -I/usr/lib/ocaml -c -o gmp_caml.o gmp_caml.c
gcc -Wcast-qual -Wswitch -Werror-implicit-function-declaration -Wall -Wextra 
-Wundef -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wno-unused 
-std=c99 -U__STRICT_ANSI__ -fPIC -O3 -DNDEBUG -DHAS_MPFR=1 -I/usr/include 
-I/usr/include -I/usr/lib/ocaml -I/usr/lib/ocaml -c -o mpz_caml.o mpz_caml.c
gcc -Wcast-qual -Wswitch -Werror-implicit-function-declaration -Wall -Wextra 
-Wundef -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wno-unused 
-std=c99 -U__STRICT_ANSI__ -fPIC -O3 -DNDEBUG -DHAS_MPFR=1 -I/usr/include 
-I/usr/include -I/usr/lib/ocaml -I/usr/lib/ocaml -c -o mpq_caml.o mpq_caml.c
gcc -Wcast-qual -Wswitch -Werror-implicit-function-declaration -Wall -Wextra 
-Wundef -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wno-unused 
-std=c99 -U__STRICT_ANSI__ -fPIC -O3 -DNDEBUG -DHAS_MPFR=1 -I/usr/include 
-I/usr/include -I/usr/lib/ocaml -I/usr/lib/ocaml -c -o mpf_caml.o mpf_caml.c
gcc -Wcast-qual -Wswitch -Werror-implicit-function-declaration -Wall -Wextra 
-Wundef -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wno-unused 
-std=c99 -U__STRICT_ANSI__ -fPIC -O3 -DNDEBUG -DHAS_MPFR=1 -I/usr/include 
-I/usr/include -I/usr/lib/ocaml -I/usr/lib/ocaml -c -o mpfr_caml.o mpfr_caml.c
gcc -Wcast-qual -Wswitch -Werror-implicit-function-declaration -Wall -Wextra 
-Wundef -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wno-unused 
-std=c99 -U__STRICT_ANSI__ -fPIC -O3 -DNDEBUG -DHAS_MPFR=1 -I/usr/include 
-I/usr/include -I/usr/lib/ocaml -I/usr/lib/ocaml -c -o gmp_random_caml.o 
gmp_random_caml.c
ar rc libgmp_caml.a gmp_caml.o mpz_caml.o mpq_caml.o mpf_caml.o mpfr_caml.o 
gmp_random_caml.o
ranlib libgmp_caml.a
/usr/bin/ocamlmklib -ocamlc /usr/bin/ocamlc.opt -verbose -o gmp -oc gmp_caml 
mpz.cmo mpzf.cmo mpq.cmo mpqf.cmo mpf.cmo mpfr.cmo mpfrf.cmo gmp_random.cmo 
-L/usr/lib -lmpfr -L/usr/lib -lgmp -L/usr/lib/ocaml -lcamlidl
+ /usr/bin/ocamlc.opt -a  -o gmp.cma  mpz.cmo mpzf.cmo mpq.cmo mpqf.cmo mpf.cmo 
mpfr.cmo mpfrf.cmo gmp_random.cmo -dllib -lgmp_caml -cclib -lgmp_caml   -cclib 
-L/usr/lib/ocaml -cclib -L/usr/lib -cclib 

Bug#768112: slurm-client: fails to upgrade from 'wheezy' - trying to overwrite /usr/bin/sinfo

[Mehdi Dogguy]

Control: reassign 768112 slurm-llnl,sinfo
Control: found 768112 slurm-llnl/14.03.9-5
Control: found 768112 sinfo/0.0.47-3
Control: tags 768112 + sid stretch

On Wed, Nov 05, 2014 at 03:27:38AM +0100, Andreas Beckmann a...@debian.org 
wrote:
   Selecting previously unselected package slurm-client.
   Unpacking slurm-client (from .../slurm-client_14.03.9-3_amd64.deb) ...
   dpkg: error processing 
 /var/cache/apt/archives/slurm-client_14.03.9-3_amd64.deb (--unpack):
trying to overwrite '/usr/bin/sinfo', which is also in package sinfo 
 0.0.46-2
   dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
   Errors were encountered while processing:
/var/cache/apt/archives/slurm-client_14.03.9-3_amd64.deb
 

This bug applies to both slurm-llnl and sinfo.

Regards,

-- 
Mehdi Dogguy


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#779115: polygen: diff for NMU version 1.0.6.ds2-13.1

[Mehdi Dogguy]

On Wed, Feb 25, 2015 at 10:17:55PM +0100, gregor herrmann gre...@debian.org 
wrote:
 
 I've prepared an NMU for polygen (versioned as 1.0.6.ds2-13.1) and
 uploaded it to DELAYED/6. Please feel free to tell me if I
 should delay it longer.
 

Thanks for your upload! Feel free to reschedule it in DELAYED/0.

Thanks again!

-- 
Mehdi Dogguy


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775619: seaborn: FTBFS in jessie: Tests failures

[Mehdi Dogguy]

On Sun, Feb 15, 2015 at 01:49:32PM -0500, Yaroslav Halchenko 
deb...@onerussian.com wrote:
 
 Yeah Stuart, thank you for the analysis... I even tried to figure out
 shim for compatibility but gave up and decided to let it die off from
 jessie encouraging people  just to fetch recent one from NeuroDebian
 alongside with more recent statsmodels.  But if I do get a moment today
 I will try to push the 2nd one suppressing functionality (so it spits
 out explicit error) and leading for
 SkipTest for those few functions which depend on new statsmodels.  But
 that is only if I find strength/time later today and otherwise tomorrow
 it would get plunged from jessie.
 

Any news? Should we add a removal hint for seaborn?

Regards,

-- 
Mehdi Dogguy


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775619: seaborn: FTBFS in jessie: Tests failures

[Mehdi Dogguy]

On Thu, Feb 19, 2015 at 09:50:40PM -0500, Yaroslav Halchenko y...@debian.org 
wrote:
 tags -1 pending
 
 On Thu, 19 Feb 2015, Yaroslav Halchenko wrote:
   Any news? Should we add a removal hint for seaborn?
 
  Since you haven't removed yet -- gimme please few more days, I will fix
  it up for jessie
 
 I have just uploaded -3 with fixes for mentioned FTBFS and few others
 which could happen if built on 32 bit
 

What is the impact of disabling statsmodels 0.6 features in seaborn?
Also, AFAICS, the runtime error is not catched, so I guess the program
will just kill itself?

Why not just setting _has_statsmodels=False when statsmodels version
is older than 0.6?

Regards,

-- 
Mehdi Dogguy


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#777540: The libhtp SONAME mismatch *is* a policy violation.

[Mehdi Dogguy]

Le 2015-02-16 23:09, Hilko Bengen a écrit :

* Julien Cristau:

1. Override upstream's decision to change the SONAME with every 
release.

   I am not entirelysure how stable libhtp's API/ABI should be
   considered -- looking at changes and deciding on compatibility 
issues
   making those decisions would certainly put a burden on the 
maintainer

   in the future (although the .symbols mechanism helps for obvious
   cases such as removed APIs.)

   I am attaching a patch to drop the -release parameter from the
   libtool call, libhtp.so.1.0.0 (instead of libhtp-0.5.15.so.1.0.0) 
is
   generated. The .symbols file would need to be updated to reflect 
that

   change, too, of course.

2. Since suricata is the only reverse dependency of libhtp and 
contains

   a copy of libhtp within its source tarball, so we could drop the
   libhtp package altogether and use that embedded copy instead, at
   least for the jessie release.

3. Change the binary package name to reflect the SONAME -- for 
instance

   libhtp-0.5.15. I believe that we are too late in the freeze to be
   adding new binary package names.


For jessie, 2 sounds like the best way to go IMO.




Removal hint added for libhtp.


Thank you. Could somebody please decide about #777042 (unblock:
suricata/2.0.6-1)?



It was unblocked.

Regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768112: fixed in slurm-llnl 14.03.9-4

[Mehdi Dogguy]

Hi Adam,

Thanks for adding the tag and for the unblock!

Le 2014-11-26 20:08, Adam D. Barratt a écrit :


I'm not sure acceptable is really the right word, and I've argued 
with

myself a bunch over this, particularly given that sinfo+slurm-llnl is
basically a closed set for dependency purposes, with a combined popcon
of ~100.



FWIW, slurm-llnl falls in the case of the packages usually installed in
environments without any internet connectivity or where popcon is 
disabled.
At work here, FWIW, we have _thousands_ of machines using this package. 
I
also know a few similar places with the same size and configuration. 
Slurm

is the most used job scheduler in the HPC world. It became a reference
in the field.

So really, popcon should not be a way to appreciate the importance of 
the

package. I agree it is not easy though since we don't always have the
necessary data to measure that.

Regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771177: develock-el: breaks c++ mode in sid and jessie

[Mehdi Dogguy]

Le 2014-11-27 12:25, Francois Marier a écrit :

Package: develock-el
Version: 0.39-1
Severity: grave
Justification: renders package unusable

This package completely breaks the standard emacs c++ mode.



I can agree that the package can be of no interest for you when
it breaks the C++ mode, but it can be no way an argument to make
this bug RC since all features of the package are not broken, on
the contrary.

And, fwiw, I am absolutely against upgrading the package _now_ to
0.45. I'll look more closely at the package instead to see if some
smaller fix can be found.

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771177: NMU submitted to the delayed/5 queue

[Mehdi Dogguy]

Le 2014-11-28 11:47, Francois Marier a écrit :
I've taken the liberty to fix this via an NMU in the delayed/5days 
queue.




I've taken the liberty to cancel it. Can you please test Matt's patch?

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768112: fixed in slurm-llnl 14.03.9-4

[Mehdi Dogguy]

Le 2014-11-08 10:53, Adam D. Barratt a écrit :

Control: reopen -1

On 2014-11-06 10:21, Gennaro Oliva wrote:

Source: slurm-llnl
Source-Version: 14.03.9-4
We believe that the bug you reported is fixed in the latest version 
of

slurm-llnl, which is due to be installed in the Debian FTP archive.

[...]

 slurm-llnl (14.03.9-4) unstable; urgency=medium
 .
   * Declaring slurm-client conflict with sinfo (Closes: #768112)


No. Please re-read policy (specifically 10.1) - you don't get to
conflict with other packages just because you both want to use the
same file path.



I think that Gennaro fixed it that way because we were aware of this
issue (which is here since before Lenny, fwiw) and we agreed with 
Gaudenz
(sinfo's co-maintainer) to find a real solution to implement in 
Jessie+1.
Gaudenz has also some trouble contacting the other co-maintainer of 
sinfo
and wasn't able to explain its name. So we were a bit stuck. Besides, 
since
the conflicts is already present in previous releases of Debian and 
since
we need to support upgrades, don't we need a conflicts statement 
anyway?

(Maybe a versioned one if the situation is sorted out before the freeze
but still)

So, is it acceptable to keep this workaround for Jessie and work on a 
better
one for Jessie+1? That way, we hope to find time enough time to work 
this

in coordination with both upstreams.

Kind regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764441: sinfo and slurm-client: error when trying to install together

[Mehdi Dogguy]

Control: reassign 764441 sinfo
Control: fixed 764441 0.0.47-2

Le 2014-10-11 23:58, Gaudenz Steinlin a écrit :

Hi

Mehdi Dogguy me...@dogguy.org writes:


Le 2014-10-09 22:55, Gaudenz Steinlin a écrit :


I will certainly update the Conflict if we can't agree on a better
solution in the next few days. But as the Conflict was a workaround
from
the begining I'd prefer a solution where we agree on different names
for
the commands instead.



I very much agree with what you say, but I think it is rather late to
find
a stable name (where also upstream is confortable with) in time for
Jessie.
There are only a few days left before the freeze.

For that reason, I prefer to keep the old (and not so nice) 
workaround

and
work on a better solution to implement in Jessie+1.


I've now uploaded a package with the conflict updated to slurm-client.


Thanks. This is very much appreciated! (and marked as such) Besides, 
please

note that you should still conflict with the old binary package name to
support partial upgrades.


But I would still like to hear from the slurm maintainers and from
Jürgen Rinas (sinfo upstream and Debian co-maintainer) about the
possibility of renaming one of the commands. I would still very much
prefer that solution.



What is the meaning of sinfo in the context of tool for monitoring
computer clusters using broadcasts?

Regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764441: sinfo and slurm-client: error when trying to install together

[Mehdi Dogguy]

Le 2014-10-12 22:59, Gaudenz Steinlin a écrit :

Hi

Mehdi Dogguy me...@dogguy.org writes:


Control: reassign 764441 sinfo
Control: fixed 764441 0.0.47-2

Le 2014-10-11 23:58, Gaudenz Steinlin a écrit :

Hi

Mehdi Dogguy me...@dogguy.org writes:


Le 2014-10-09 22:55, Gaudenz Steinlin a écrit :


I will certainly update the Conflict if we can't agree on a better
solution in the next few days. But as the Conflict was a 
workaround

from
the begining I'd prefer a solution where we agree on different 
names

for
the commands instead.



I very much agree with what you say, but I think it is rather late 
to

find
a stable name (where also upstream is confortable with) in time for
Jessie.
There are only a few days left before the freeze.

For that reason, I prefer to keep the old (and not so nice)
workaround
and
work on a better solution to implement in Jessie+1.


I've now uploaded a package with the conflict updated to 
slurm-client.


Thanks. This is very much appreciated! (and marked as such) Besides,
please
note that you should still conflict with the old binary package name 
to

support partial upgrades.


Just to be sure and to not have to do yet another upload. Adding a
conflict against slurm-llnl  ( 14.03.8-1) would be right, as 
according

to the slurm-llnl changelog that's the version where the packages were
renamed.



IMHO, you can leave the conflicts statement on slurm-llnl unversioned 
as
even the new one depends on slurm-client which brings sinfo. Otherwise, 
yes,

14.03.8-1 is the correct version.


And wouldn't it be better to also add a conflict on the slurm-client
side? This would at least prevent a similar bug if the package get's
renamed again.



We can do that. I'll first wait until it migrates to testing and then 
do

a second upload adding that.

Regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764441: sinfo and slurm-client: error when trying to install together

[Mehdi Dogguy]

Le 2014-10-09 22:55, Gaudenz Steinlin a écrit :


I will certainly update the Conflict if we can't agree on a better
solution in the next few days. But as the Conflict was a workaround 
from
the begining I'd prefer a solution where we agree on different names 
for

the commands instead.



I very much agree with what you say, but I think it is rather late to 
find
a stable name (where also upstream is confortable with) in time for 
Jessie.

There are only a few days left before the freeze.

For that reason, I prefer to keep the old (and not so nice) workaround 
and

work on a better solution to implement in Jessie+1.

Regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764441: sinfo and slurm-client: error when trying to install together

[Mehdi Dogguy]

Hi Gaudenz,

On Wed, Oct 08, 2014 at 10:34:45AM +0200, Gaudenz Steinlin gaud...@debian.org 
wrote:
 
 Ralf Treinen trei...@free.fr writes:
 
  Here is a list of files that are known to be shared by both packages
  (according to the Contents file for sid/amd64, which may be
  slightly out of sync):
 
/usr/bin/sinfo
/usr/share/man/man1/sinfo.1.gz
 
 This happends because the sinfo binary in slurm moved from slurm-llnl to
 slurm-client and now the conflict specified in sinfo is wrong. To
 restore the previous state, sinfo should update it's conflict to
 slurm-client with appropriate versioning.
 

Since your package had a Conflicts, can you please update it? If you agree
on that, can you also reassign this bug to src:sinfo so that it is tracked
properly?

Cheers.

-- 
Mehdi Dogguy


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752945: oasis: FTBFS - 2 test failures

[Mehdi Dogguy]

Control: severity 752945 important

Le 2014-08-09 11:39, Mehdi Dogguy a écrit :


If I don't have a way to reproduce this bug, I guess I'll downgrade
the severity to important.



I tried to run some more tests in different contexts but wasn't able
to reproduce the described failures. Thus, I'm downgrading this issue
to important.

Kind regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752945: oasis: FTBFS - 2 test failures

[Mehdi Dogguy]

Hi,

Le 2014-06-28 02:01, Michael Tautschnig a écrit :

Package: oasis
Version: 0.4.4-2
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using 
cowbuilder

and pbuilder) the build failed with the following error.

[...]
expected: Exited with code 0 but got: Exited with code 1
--
==
Error: OASIS:5:TestFull:0:best=native:5:examples/with-c.

File
/srv/jenkins-slave/workspace/sid-goto-cc-oasis/oasis-0.4.4/_build/oUnit-OASIS-mt-farm05#02.log,
line 394, characters 1-1:
Error: OASIS:5:TestFull:0:best=native:5:examples/with-c (in the log).

File test/TestFullUtils.ml, line 419, characters 1-1:
Error: OASIS:5:TestFull:0:best=native:5:examples/with-c (in the code).

Exit status of command 
'/tmp/ounit-e59f4c-mt-farm05#02.dir/precompile/setup

-info -debug -all -- --override is_native true'
expected: Exited with code 0 but got: Exited with code 1
--
Ran: 227 tests in: 57.08 seconds.
FAILED: Cases: 227 Tried: 227 Errors: 0 Failures: 2 Skip:  4 Todo: 0
Timeouts: 0.


I've been unable to reproduce this build failure. The with-c passes 
with success in the two
cases here (native and byte). Are you able to reproduce this build 
failure outside Jenkins
and directly using cowbuilder or pbuilder? Or, provide us the produced 
log files to be able to

investigate further? Or, better, the full build directory.

My full build log is attached.

If I don't have a way to reproduce this bug, I guess I'll downgrade the 
severity to important.


Kind regards,

--
Mehdi

oasis-build-log-success.txt.gz
Description: Binary data

Bug#751693: libjs-of-ocaml-dev: Broken dependencies render unrelated packages FTBFS

[Mehdi Dogguy]

Le 2014-06-15 18:58, Michael Tautschnig a écrit :


It seems that those depended-on packages don't even exist anymore. 
Maybe a
BinNMU is all that is needed, but I'm quite surprised how these 
dependencies

ever came about.




A new upstream release of ocaml-deriving-ocsigen has been uploaded 
yesterday.
So the binNMU is indeed all that is needed (if the 
ocaml-deriving-ocsigen's
API didn't change, of course). I'll let Stéphane handle them though, 
maybe

he has more changes to implement in the affected packages.

Best,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749863: jocaml: FTBFS - applying patches fails

[Mehdi Dogguy]

Control: tag 749863 + pending

Hi,

Le 2014-05-30 12:10, Michael Tautschnig a écrit :


Presumably the ocaml sources have changed? (The buildds used ocaml 
4.01.0-3, but

the archive now has 4.01.0-4.)



It seems that the last patch from OCaml depends on an another patch (in 
the queue).
So, the import order is important. I have to admit that I didn't pay 
attention to
how quilt import works. It seems that quilt import 1.patch; quilt 
import 2.patch
puts 2 before 1. Adding a sort -r upon import is enough to fix this 
build failure.


Thanks for your bug report!

Regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745307: Re-assigning to OCamlgraph

[Mehdi Dogguy]

Le 2014-05-07 21:51, Peter Michael Green a écrit :

This bug is due to an API change appeared in
OCamlgraph 1.8.4 and then reverted
back in 1.8.5. OCamlgraph 1.8.3 (present
testing's version) is not affected.

Am I correct in thinking that means that the binnmus for dose3 should
be given back?


Yes. Thanks for the notice. I just did that now.

Regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745307: Re-assigning to OCamlgraph

[Mehdi Dogguy]

Control: reopen 745307
Control: reassign 745307 ocamlgraph 1.8.4-1
Control: close 745307 1.8.5-1


This bug is due to an API change appeared in OCamlgraph 1.8.4 and then 
reverted
back in 1.8.5. OCamlgraph 1.8.3 (present testing's version) is not 
affected.



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745307: FTBFS with ocamlgraph 1.8.4

[Mehdi Dogguy]

Le 2014-04-20 13:13, Stéphane Glondu a écrit :

Source: dose3
Version: 3.1.3-7
Severity: serious

Dear Maintainer,

dose3 fails to build with the latest version of ocamlgraph (1.8.4).



It seems that ocamlgraph's upstream reverted the specific part that
changed its API. Thus, dose3 should build just fine now using the newly
released ocamlgraph 1.8.5, which I just uploaded.

I'll close this bug later, when ocamlgraph/1.8.5 will be available on
all archs.

--
Mehdi Dogguy


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745307: FTBFS with ocamlgraph 1.8.4

[Mehdi Dogguy]

Le 2014-04-27 12:41, Ralf Treinen a écrit :

On Sun, Apr 27, 2014 at 11:19:40AM +0200, Mehdi Dogguy wrote:

Le 2014-04-20 13:13, Stéphane Glondu a écrit :

Source: dose3
Version: 3.1.3-7
Severity: serious

Dear Maintainer,

dose3 fails to build with the latest version of ocamlgraph (1.8.4).



It seems that ocamlgraph's upstream reverted the specific part that
changed its API. Thus, dose3 should build just fine now using the 
newly

released ocamlgraph 1.8.5, which I just uploaded.

I'll close this bug later, when ocamlgraph/1.8.5 will be available on
all archs.


OK, merci. The next upload of dose3 will exclude in its 
build-dependency
libocamlgraph-ocaml-dev 1.8.4-1 (since this will also be needed for 
dose 3.2).




Can you be more specific about the will exclude in its 
build-dependency
libocamlgraph-ocaml-dev 1.8.4-1 part please? What does it mean 
technically?


IMHO, it is enough to bump the build-dep to 1.8.5-1~ and not do 
anything else.


Regards,

--
Mehdi Dogguy


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730526: why: uninstallable on sid

[Mehdi Dogguy]

Le 2013-11-26 08:01, Johan Gronqvist a écrit :


   * What led up to the situation?
 The package frama-c was updated to a new upstream version in
sid, but the versioned dependency in frama-c was not updated, which
makes the package why uninstallable in sid on amd64 (and others).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Try to upgrade frama-c without removing why.



Yes, this is expected as we are in the middle of a tiny transition. The 
situation

should be fixed soon. It needs apron to be fixed first though.

For now, the immediate solution is to use testing's packages.

Regards,

--
Mehdi


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718098: menhir: diff for NMU version 20120123.dfsg-1.1

[Mehdi Dogguy]

Le 2013-11-13 21:58, gregor herrmann a écrit :


Please feel free to tell me if I should delay it longer.



You should really not ;) Feel free to reschedule it in delayed/0.

Thanks for your work!


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704208: missing dependency on python2.6

[Mehdi Dogguy]

On 03/29/2013 03:41 PM, John Paul Adrian Glaubitz wrote:
 On 03/29/2013 03:38 PM, Christoph Egger wrote:
 Because in unstable/wheezy python depends on python2.7 not python2.6. if
 you depend on python you can assume /usr/bin/python but not either of
 python2.6 and python2.7
 
 Ah, you're right. Thanks for the heads-up. I'll be there with a debdiff
 showing my suggested NMU.
 

Any news here?

Regards,

-- 
Mehdi


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#692274: asciidoc: a2x uses xmllint by default internally, but does not depend on libxml2-utils

[Mehdi Dogguy]

severity 692274 important
thanks

Arno Töll a...@debian.org wrote:
 Package: asciidoc
 Version: 8.6.7-1
 Severity: serious
 Justification: Policy 7.2
 
 a2x internally uses xmllint by default. It can be disabled on the command 
 line,
 but it is used by default. This yields to build failures in deterministic 
 setups,
 where recommends are not installed by default, e.g. Debian buildds.
 
 I don't think recommending libxml2-utils is good enough, unless you make the
 absence of xmllint non fatal. That's a problem for example to packages build
 depending on asciidoc, but not on libxml2-utils when compiling manpages from
 source as required by policy 2.2.1. That would cause build failures like:
 

Such packages should be fixed to add the necessary build-dependency then.

This issue is not RC, since the package lacks a hard dependency
relation for an optional dependency. Things could be improved (as you
duly noted) by changing the default, detecting available dependencies
or adding recommends to the package but this still doesn't justify an
RC severity. I'm lowering the severity to important.

Best,

-- 
Mehdi Dogguy


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#689551: icinga-common: ships /var/run/icinga (policy 9.1.4)

[Mehdi Dogguy]

severity 689551 important
thanks

On 04/10/2012 00:49, Andreas Beckmann wrote:
 Package: icinga-common
 Version: 1.7.1-4
 Severity: serious
 
 Hi,
 
 I noticed that icinga-common ships /var/run/icinga, which is forbidden
 by policy 9.1.4:
 http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs-run
 [...] Packages must not include files or directories under /run, or
 under the older /var/run and /var/lock paths. [...]
 

It is not RC though. And concerning its init script, it takes care of
creating /var/run/icinga if not present before launching the daemon?

Regards,

-- 
Mehdi Dogguy مهدي الدڤي


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#678979: request freeze exception for slony1-2

[Mehdi Dogguy]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21/09/2012 04:58, Peter Eisentraut wrote:
 According to bug #678979 [0], which was submitted by the lead 
 upstream developer, slony 2.0 does not work well with postgresql
 9.1. Therefore, we had to resolve to making an upgrade to slony
 version 2.1, and I request that that be allowed into wheezy now.
 
 To be precise: The source package name is slony1-2.
 

Unfortunately, we are not able to accept such large changes at this
stage of the freeze. [2]

Since slony in Debian have little popcon, does it make sense to skip the
Wheezy release? iow, remove slony from wheezy (since it doesn't work and
we are not able to accept the new one). Alternatively, we could very
well accept a targeted fix based on current Wheezy's version… (correct
me if I'm wrong), the discussion in #678979 made me think that it was
not possible to extract a minimal patch.

Besides, once Wheezy is released, you may upload sid's version to
wheezy-backports so that wheezy users can enjoy it as well. You'll also
be able to update it more often than you might do in a stable release.

[2] 333 files changed, 49485 insertions(+), 13745 deletions(-)

 
 [0]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678979
 
 [1]: http://packages.qa.debian.org/s/slony1-2.html

Kind regards,

- -- 
Mehdi Dogguy مهدي الدڤي
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQcXXvAAoJEDe1GR0FRlJoCZIH/2NVSzPWb6Nl+6IWG4aq8aRz
E/syjXfLbdIkAljxWrEgLbUHIgZiiHKQhWfhRR3oyvpvCfZ7/ak1QaK8YGy1tj6b
FwkOVzcLPjPmQXoYtyhMtbOnTPFkb9F/V6auROLQ/NyJMro1FAT+Y0/6gnDVRZ69
CPN6iVFwVxiWzNVK9SqMyKanwj+6u0lhBU7rzqjXgnD403Hl6a8G7KbLp1PGW+bk
tsLYSMjCq3gQrvn2CqiuP/GSpW1Qz30o7OF3HzRltlfy/SM5ebN3XZBzyixRrUhk
8Y/415uIHP37ULAUc+OeFKLu+Bx9xP0hdQcb85X+h+cmCvKcZeyfWqwLxqLwrbs=
=irBk
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#689899: Ships a folder in /var/run or /var/lock (Policy Manual section 9.3.2)

[Mehdi Dogguy]

severity 689899 important
thanks

On 07/10/2012 17:10, Thomas Goirand wrote:
 +  * mgetty-fax doesn't ship /var/run/mgetty-fax anymore (Closes: #XX).

Shipping a file or directory under /var/run is not RC. What's RC is to
not check for the existence of (e.g.) /var/run/mgetty before using it.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#689894: Ships a folder in /var/run or /var/lock (Policy Manual section 9.3.2)

[Mehdi Dogguy]

tags 689894 - patch
thanks

On 07/10/2012 17:06, Thomas Goirand wrote:
 
 Please fix your package. I have attached what I believe is a good fix
 the problem, however, I haven't tried it, and I haven't tested if
 something more for creating the necessary folder at runtime should be
 added. Please make sure to test before applying the patch blindly.
 

Can you please explain how your patch fixes the problem? AFAICS, you
don't re-create /var/run/jabberd2 anywhere.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#689894: Ships a folder in /var/run or /var/lock (Policy Manual section 9.3.2)

[Mehdi Dogguy]

On 07/10/2012 19:07, Thomas Goirand wrote:
 On 10/08/2012 12:19 AM, Mehdi Dogguy wrote:
 tags 689894 - patch thanks
 
 On 07/10/2012 17:06, Thomas Goirand wrote:
 
 Please fix your package. I have attached what I believe is a good
 fix the problem, however, I haven't tried it, and I haven't
 tested if something more for creating the necessary folder at
 runtime should be added. Please make sure to test before applying
 the patch blindly.
 
 
 Can you please explain how your patch fixes the problem? AFAICS,
 you don't re-create /var/run/jabberd2 anywhere.
 
 
 Right. for this one.

Not only…

 I haven't find out yet where to add the creation of the run dir for
 at least 2 packages. As I couldn't remember which package were needed
 it.

Then do not add patch tag where there is no patch.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#678720: sugar-0.96: diff for NMU version 0.96.1-2.1

[Mehdi Dogguy]

Simon Paillard spaill...@debian.org wrote:

 I've prepared an NMU for sugar-0.96 (versioned as 0.96.1-2.1) and
 uploaded it to DELAYED/4. Please feel free to tell me if I
 should delay it longer.
 

As far as I can see, your patch does not fix all problems. The
submitter did show the following errors at sugar's startup:

 /usr/bin/sugar: 3: [: missing ]
 /usr/bin/sugar: 3: /usr/bin/sugar: 1000: not found

and there is indeed ] and [ missing around the || operator.
Furthermore, the package is missing another dependency to be able to
use xrdb. So, afaics, it needs to depend on x11-xserver-utils. I guess
setting -e helps...

I can file those issues seperately if preferred (and they would have
severity serious).

I didn't inspect the package further. There might be more issues.

Regards,

-- 
Mehdi Dogguy


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#632604: libatomic-ops: diff for NMU version 7.3~alpha1+git20111031-1.1

[Mehdi Dogguy]

On 03/10/2012 06:40, Ian Wienand wrote:

On Tue, Oct 2, 2012 at 8:35 AM, gregor herrmanngre...@debian.org  wrote:

Ian, if your busy I'm happy to upload the fix (if Mehdi is ok with
the diff).


Many thanks for looking into this.  I'd be glad if you can upload; I
would only upload the same thing anyway.



Thanks for both of you. You can go ahead with the upload. It will 
probably be better to use 7.2~alpha5+cvs20101124-1+deb7u0 as version 
number.


Regards,

--
Mehdi Dogguy مهدي الدڤي


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#687026: gnome-shell: No browser icon in dash

[Mehdi Dogguy]

Paul Menzel pm.deb...@googlemail.com wrote:
 
 Talking with mbiebl and Np237 in #debian-gnome on irc.oftc.net, Np237
 said that this corresponding change has been made for epiphany-browser,
 but the updated packages has not yet been uploaded.
 

I guess this bug is fixed now that /3.4.2-2 has been uploaded, no?

See [1] for the relevant change.

[1] 
http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-shell/debian/gnome-shell.gsettings-override?r1=35528r2=35762

Regards,

-- 
Mehdi Dogguy


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#632604: libatomic-ops: diff for NMU version 7.3~alpha1+git20111031-1.1

[Mehdi Dogguy]

On 21/06/2012 18:39, gregor herrmann wrote:

tags 632604 + pending
thanks

Dear maintainer,

I've prepared an NMU for libatomic-ops (versioned as 
7.3~alpha1+git20111031-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.



We may need this patch after all :) It seems that #632604 and sid's 
libatomic-ops cannot be unblocked for Wheezy (due to very large changes 
in its codebase). Could you please prepare an upload targetting 
testing-proposed-updates?


Regards.

--
Mehdi Dogguy مهدي الدڤي


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#672156: Should be dropped in favour of squid3

[Mehdi Dogguy]

tags 672156 + wheezy-ignore
thanks

On 02/07/2012 04:07, Amos Jeffries wrote:

Are the release team willing to accept a squid-3.2.1 stable release
upload 4-6 weeks after Wheezy freeze?

That upload will close this RC bug, a CVE security bug in both squid
and squid3 packages, and a number of regular bugs.

Notice the Ubuntu effort to migrate 2.7 package to 3.1 ahead of
upstream is identifying a number of new bugs caused by the early
upgrade. Both in packaging issues and configuration file upgrade
issues.



It seems that nothing happened here and the migration between
squid/squid3 doesn't seem all working yet. Since we cannot accept large
changes anymore, I think the best option is to postpone this bug for
Jessie. (Note: Moritz (CC'ed) said on IRC that he is okay with this plan).

Regards,

--
Mehdi Dogguy مهدي الدڤي


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688053: asterisk: SIP module fails to load

[Mehdi Dogguy]

On 27/09/2012 14:15, Mehdi Dogguy wrote:


… was uploaded to stable-security-updates.



err, in stable-security.

--
Mehdi Dogguy مهدي الدڤي


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#684433: gdal: diff for NMU version 1.9.0-3.1

[Mehdi Dogguy]

On 18/09/2012 17:50, gregor herrmann wrote:


I've prepared an NMU for gdal (versioned as 1.9.0-3.1) and uploaded
it to DELAYED/2. Please feel free to tell me if I should delay it
longer.



I see there is a binary package libgdal-ruby1.8 from source package 
gdal. Do we need both?


Regards,

--
Mehdi Dogguy


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#684433: gdal: diff for NMU version 1.9.0-3.1

[Mehdi Dogguy]

On 19/09/2012 16:29, gregor herrmann wrote:

- a binary package libgdal-ruby (meta package depending on
   libgdal-ruby1.8)



Hmpf… Sorry, I missed this point. I checked the list of packages on the 
PTS and didn't try to analyze inter-packages relations further.


Regards,

--
Mehdi Dogguy


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#687925: diff for NMU version 1.4.20.2-10.1

[Mehdi Dogguy]

On 17/09/2012 15:49, Ritesh Raj Sarraf wrote:

Given the freeze, I am not hopeful of it getting in for Wheezy.


Doesn't look so awful to not be unblocked. Why do you think the
contrary? (It still needs to be acked by -boot folks though)

--
Mehdi Dogguy


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org