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

On 2021-01-27 15:49, Laurent Bonnaud wrote: On 1/23/21 9:07 PM, Mehdi Dogguy wrote: Thanks for the bugreport and sorry for not replying earlier! No problem! I wasn't able to reproduce this bug. Thanks for trying! FWIW, I've just uploaded dochelp 0.1.8 with a couple of bugfixes (none

Bug#980968: doc-base could suggest dochelp

Package: doc-base Version: 0.11 Severity: wishlist Hi, I created dochelp some years ago to have simple yet effective tool to browse doc-base registered documentation installed on one's system. dochelp doesn't require any webserver or heavy tool. It generates a static web page which allows

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

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

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

> Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages dochelp depends on: > ii libc6 2.29-4 > ii libjs-jquery 3.3.1~dfsg-3 > ii libpcre3 2:8.39-12+b1 > > dochelp recommends no packages. > > dochelp suggests no packages. > > -- no debconf information > > -- > Laurent. -- Mehdi Dogguy

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

gt; ProtectKernelTunables=yes > ProtectSystem=strict > ReadWritePaths=/var/lib/mldonkey > RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 > RestrictRealtime=yes > StateDirectory=mldonkey > SystemCallArchitectures=native > Type=simple > User=mldonkey > WorkingDirectory=/var/lib/mldonkey > > [Install] > WantedBy=multi-user.target -- Mehdi Dogguy

Bug#876966: marked as pending in ben

On 2021-01-05 22:07, Christoph Berg wrote: Re: Mehdi Dogguy Bug #876966 in ben reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit I pulled scripts.js manually and change works nicely. Thanks! Thanks a lot for checking, Christoph! Happy

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

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

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

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

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

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

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

Hi Jonas, On 2018-10-15 19:54, Lippuner, Jonas wrote: I'm having the same issue with libpsm2-2 version 11.2.68-1. Downgrading to 10.3.58-2 fixes it for me. Can you please explain how you experienced the bug? I've understood Drew's case, but maybe yours is slightly different. -- Mehdi

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

On 2018-09-09 10:44, Ralf Jung wrote: Hi Mehdi, On 2018-09-07 12:42, Ralf Jung wrote: Package: opam Version: 2.0.0-2 Severity: normal Dear Maintainer, Quoting from https://opam.ocaml.org/doc/2.0/External_solvers.html: As of 2.0.0, opam comes with a CUDF solver built-in by default, so

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

Hi Ralf, On 2018-09-07 12:42, Ralf Jung wrote: Package: opam Version: 2.0.0-2 Severity: normal Dear Maintainer, Quoting from https://opam.ocaml.org/doc/2.0/External_solvers.html: As of 2.0.0, opam comes with a CUDF solver built-in by default, so unless you have specifically compiled without

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

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

Bug#907042: opam 1.2.0 is deprecated (jessie)

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 ins

Bug#907042: opam 1.2.0 is deprecated (jessie)

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

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

Indeed :-) Le 22 juin 2018 05:00:35 GMT+02:00, Andy Li a écrit : >On Fri, Jun 22, 2018 at 5:01 AM, Mehdi Dogguy wrote: >> Excellent work! I've reviewed it and it looks fine. I'll upload it >shortly. >> Would you mind retitling thing bug to an "ITP: ..." and setti

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

Hi Andy, On 2018-06-20 11:52, Andy Li wrote: I've created an initial version of the package in salsa: https://salsa.debian.org/ocaml-team/ppx-tools-versioned Tested building it with sbuild (and adt-run) for both amd64 and mips. Would you review it? Excellent work! I've reviewed it and it

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

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

Bug#901132: Enable support for PSM2

Source: openmpi Version: 3.1.0-6 Severity: normal Hi, PSM2 was accepted in Debian a few weeks ago. It would be very nice to see its support enabled in OpenMPI. Cheers, -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable')

Bug#900018: FTBFS with latest cmdliner

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

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

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

Bug#900018: FTBFS with latest cmdliner

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

Bug#900018: FTBFS with latest cmdliner

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, [

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

Hi, On 2018-05-21 18:43, Sebastiaan Couwenberg wrote: Do you still have to for the documentation update? I've published new instructions on Ben's website (which is generated from Ben's git repository). You can read them here: https://ben.debian.net/#_tracker Basically, it is: $ ocamlbuild

Bug#869114: status of the topkg package

Hi, On 2018-05-21 08:49, Andy Li wrote: Hi Hendrik, What is the status of the topkg package? I want to update jsonm, which now depends on topkg. FWIW, I updated jsonm today using a custom debian/rules file (the famous debian/rules file used for pretty much all Daniel's software packaged in

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

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

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

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

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

On 2018-05-14 18:46, Sebastiaan Couwenberg wrote: On 05/14/2018 08:26 AM, Mehdi Dogguy wrote: On 2018-05-14 08:01, Sebastiaan Couwenberg wrote: Unfortunately that doesn't apply cleanly on top of 0.7.4 for stretch. If you can provide a rebased commit for 0.7.4 I'm willing to test

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

On 2018-05-14 08:01, Sebastiaan Couwenberg wrote: Unfortunately that doesn't apply cleanly on top of 0.7.4 for stretch. If you can provide a rebased commit for 0.7.4 I'm willing to test that. No problem. Here it is (attached). Thanks for your tests! Kind Regards, -- Mehdi--- a/_tags +++

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

On 2018-05-13 21:10, Sebastiaan Couwenberg wrote: I've applied that commit on top of ben (0.7.4) from stretch, and it resolves this issue. The Packages & Sources files are no longer downloaded again when `ben tracker ...` is executed, and the various settings from the global.conf files are used

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

On 2018-05-13 21:10, Sebastiaan Couwenberg wrote: On 05/13/2018 08:32 PM, Mehdi Dogguy wrote: On 2018-05-13 15:44, Sebastiaan Couwenberg wrote: Those are the files in the current working directory, and may be from a different distribution. All the global.conf files use a separate cache-dir

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

On 2018-05-13 15:44, Sebastiaan Couwenberg wrote: Those are the files in the current working directory, and may be from a different distribution. All the global.conf files use a separate cache-dir but this setting has no effect any more. The same goes for the list of architectures and ignored

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

Hi Sebastiaan, On 2018-05-13 14:13, Sebastiaan Couwenberg wrote: On 05/13/2018 01:59 PM, Mehdi Dogguy wrote: On 2018-05-13 13:51, Sebastiaan Couwenberg wrote: On 05/13/2018 01:25 PM, Mehdi Dogguy wrote: On 2017-09-22 18:37, Bas Couwenberg wrote: Package: ben Version: 0.7.4+b4 Severity

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

On 2018-05-13 13:51, Sebastiaan Couwenberg wrote: On 05/13/2018 01:25 PM, Mehdi Dogguy wrote: On 2017-09-22 18:37, Bas Couwenberg wrote: Package: ben Version: 0.7.4+b4 Severity: important Dear Maintainer, Since the upgrade to stretch my ben setup no longer works as before. The `ben tracker

Bug#895166: ben: move out of asciidoc

Hi, On 2018-04-08 03:41, Joseph Herlant wrote: Package: ben Version: 0.7.7 Severity: wishlist Dear Maintainer, Asciidoc is currently facing its end of life and I'm working with the different packages that depend on it to get its EOL go smooth. There are several alternatives to asciidoc

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

Hi, On 2017-09-22 18:37, Bas Couwenberg wrote: Package: ben Version: 0.7.4+b4 Severity: important Dear Maintainer, Since the upgrade to stretch my ben setup no longer works as before. The `ben tracker --global-conf /global.conf` commands don't use the cache file as configured in the

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

Hi Andreas, Thank for you for the bugreport and throughout explanation! On 11/01/2018 13:21, Andreas Beckmann wrote: > Package: libpsm-infinipath1 > Version: 3.3+20.604758e7-4 > Severity: important > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts

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

On 12/01/2018 21:45, Hattne, Johan wrote: > >> On Jan 12, 2018, at 15:00, Mehdi Dogguy <me...@dogguy.org> wrote: >> >> I agree. My patch would only help others to not fall into the trap of >> using slurm's default pid paths. A more suitable mid-term goal would

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

Control: retitle 885759 Use /var/run as a statedir, and not /var/run/slurm-llnl On 12/01/2018 19:39, Hattne, Johan wrote: > > I’m not sure providing a consistent value in the default configuration file > would be appropriate. If one sets SlurmPidFile in slurm.conf, it will apply > to all the

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

PidFile in the appropriate configuration files for (respectively) slurmctld, slurmd and slurmdbd. I am not going to revert changes on the run directory in the debian packaging for now (as I guess my co-maintainer had good reasons to override them), but I'll change debian's provided slurm's defaults to be coherent with the reste of the package. Regards, -- Mehdi Dogguy

Bug#797535: vmpk status

Hi Ross, It is great to hear that pkg-multimedia is willing to take care of this package. Did you make any progress on this package? AFAIK, current version is broken and doesn't work anymore. An update to the latest upstream version is very much needed. Regards, -- Mehdi

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

s to Chris Lamb > for the patch. > - add 0012-Reproducible-build.patch I made a typo in the changelog and closed the wrong bug. Sorry for that. I am opening it again. Regards, -- Mehdi Dogguy

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

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

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

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Slurm 16.05.9-1 has been uploaded to Unstable a while ago and is a bug fix release. The diff is large but it contains many fixes (See summary in upstream's NEWS file) and Slurm minor

Bug#836127: Call for Votes for new CTTE Member

Hi Philip, On 10/04/2017 10:37, Philip Hands wrote: > Margarita Manterola writes: > >>> ===BEGIN >>> >>> The Technical Committee recommends that David Bremner be >>> appointed by the Debian Project Leader to the Technical Committee. >>> >>> A: Recommend to Appoint David

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

Hi, On 10/01/2017 08:58, Ralf Treinen wrote: > Hi Josch, > > On Mon, Jan 09, 2017 at 05:57:27PM +0100, Johannes Schauer wrote: >> Hi Ralf, >> >> On Sun, 6 Nov 2016 14:56:51 +0100 Helmut Grohne wrote: >>> dose-builddebcheck has a built-in architecture table and allows >>>

Bug#610835: Installing caml pulls in half the world

I thought we could finish 2016 with a nice discussion with Juliusz :-) On 25/01/2011 19:25, Juliusz Chroboczek wrote: > > While I have read the long descriptions after becoming confused by the > short descriptions, and hence before sending the report, as you suggest > above, I fail to see what

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

Hi, Thank you for your bugreport and apologies for not getting back to you sooner. On 17/06/2016 12:07, whitequark wrote: > Source: ocaml > Severity: normal > > Dear Maintainer, > > The ocaml package, as well as its sister packages ocaml-nox, ocaml-base and > ocaml-base-nox, are missing a

Bug#418965: package confluence

On 21/12/2016 20:59, Ralf Treinen wrote: > Hi Mehdi, > > On Wed, Dec 21, 2016 at 03:09:10PM +0100, Mehdi wrote: >> Hi Ralf, >> >> Did you ask for its removal? >> >> FWIW, i'm also for its removal from debian since the project is dead >> upstream. > > not yet, since there still is a

Bug#841961: nmu: ocaml_4.02.3-7

On 24/10/2016 22:07, Gilles Filippini wrote: > Please rebuild ocaml against the pie-enabled compiler chain, to fix an FTBFS > of scilab package: > FWIW, I have uploaded ocaml/4.02.3-8 to fix issues on armhf this morning. And I have just given back scilab on armhf. It /should/ fix scilab's build

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

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

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

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 C

Bug#837456: ocamlgraph needs PIE binNMU

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,

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

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}, >

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

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

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

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

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

ource 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

Bug#842776: libdose3-ocaml-dev is uninstallable

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 >

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

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

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

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 expre

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

and users, to be able to interact in a safe and pleasant environment. We are all here to make fun! So please, let's make it enjoyable the best we can. [1] https://www.debian.org/code_of_conduct All best, -- Mehdi Dogguy

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

(I noticed that you replied to the list, and not to the bugreport. I took the liberty to send my reply to the bug as well to have a complete log of the discussion. Feel free to drop the list in the subsequent replies). On 04/08/2016 22:22, Tollef Fog Heen wrote: > > One thing I don't think we're

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

On 03/08/2016 17:41, Ian Jackson wrote: > Well, not _all_ of the bullet points above are things that the TC is > (or could be) bad at. > > But, in increasing order of likely controversy: > > * By my comments about "judgemental" I meant that a "helping people >get their ideas done" team

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

Hi Philip, On 03/08/2016 10:47, Philip Hands wrote: > Conflicting goals: > > Unless it's clear that both goals will be done unless one of them is > stopped, and they are going to be in conflict from the start, I think > it's normally best to let them compete. As long as each effort is >

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

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

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

Hi marga, On 11/07/2016 12:39, Margarita Manterola wrote: > For documentation purposes, I list below my summary of the points that were > raised during the Roadmap BOF. These items are separate and may not > necessarily > all (or even any) need to be true in the implementation adopted. During

Bug#517109: grepmail: support for lzma compression

ail? > Looks like it is fixed upsteam in 5.3100. It would be nice if someone could adopt this package and update it to latest upstream version. Bonus points if maintainer makes a backport too... ;) Regards, -- Mehdi Dogguy

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

On 20/04/2016 11:50, Julien Cristau wrote: > Control: tags -1 confirmed > > On Mon, Apr 11, 2016 at 00:57:58 +0200, Mehdi Dogguy wrote: > >> Hi, >> >> On 10/04/2016 17:27, Julien Cristau wrote: >>>> --- a/debian/changelog >>>> +++ b/debi

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

flags when fetching + files using wget and curl (Closes: #818081). + + -- Mehdi Dogguy <me...@debian.org> Sun, 10 Apr 2016 12:27:13 +0200 + opam (1.2.0-1) unstable; urgency=medium * New upstream release. --- a/debian/gbp.conf +++ b/debian/gbp.conf @@ -1,4 +1,6 @@ [DEFAULT] +git-debian-b

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

and curl. + + -- Mehdi Dogguy <me...@debian.org> Sun, 10 Apr 2016 12:27:13 +0200 + opam (1.2.0-1) unstable; urgency=medium * New upstream release. --- a/debian/gbp.conf +++ b/debian/gbp.conf @@ -1,4 +1,6 @@ [DEFAULT] +debian-branch = "debian/jessie" +upstream-branch = "upst

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

On Sun, Mar 20, 2016 at 06:58:34PM +0100, Mehdi Dogguy <me...@dogguy.org> wrote: > On Thu, Nov 12, 2015 at 10:38:39AM +0100, IOhannes m zmölnig > <zmoel...@umlaeute.mur.at> wrote: > > Control: severity -1 important > > thanks. > > > > i'm unable to

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

ty of a signature though. I agree that it still does something, but I would not call the package usable. Its main purpose is really not to check signatures, but to help signing/encrypting messages. So the severity should reflect that. Regards, -- Mehdi Dogguy

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

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

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

Hi Claudio, On 25/01/2016 20:54, Claudio Sacerdoti Coen wrote: > Dear Mehdi, > > the most recent camlp5 version in git seems to fix enough bugs to let Thanks for handling this with camlp5's upstream. I can confirm it builds fine with latest two fixes in camlp5. I'll prepare fixed packages now

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

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 &g

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

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:

Bug#790422: Parsing.Parse_error

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

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

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 >

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: tags 811248 + fixed-upstream Hi, On 17/01/2016 09:52, Christoph Berg wrote: > Package: dose-builddebcheck > Version: 4.0.2-2 > Severity: normal > > Hi, > Thanks for your bugreport! > I'm just working on using the dose tools to test

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

Hi Pietro, Thanks for the quick reply! On 19/01/2016 23:41, Pietro Abate wrote: > > This change was indeed intentional. Thanks for the confirmation! > > Mehdi, where are these places in the code that still expect "src:" ? > I've removed this prefix from all the yaml output. I didn't really >

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

Hi, On 08/01/2016 06:24, Helmut Grohne wrote: > Package: dose-builddebcheck > Version: 4.1-1 > File: /usr/bin/dose-builddebcheck > User: helm...@debian.org > Usertags: rebootstrap > > Hi, > > I am one of the active consumers of dose-builddebcheck in unstable and > quickly noticed the 4.1 upload

Bug#790422: Parsing.Parse_error

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

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

Hi On 20/01/2016 01:10, Pietro Abate wrote: > Hi > > On 20/01/16 00:00, Mehdi Dogguy wrote: >> Only did a quick grep: >> >> % git grep -n "\"src:" **/*.ml >> applications/deb-buildcheck.ml:182: let (name,filter) = >> Debian.Debutil.

Bug#809225: Nice way to solve bugs and segfaults

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

Bug#807019: unison2.40.102: Segmentation fault

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

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

Package: ftp.debian.org Severity: normal Hi, Unison 2.32 is broken now that we moved to OCaml 4.02.3 (See #809225). Just like Unison 2.40, please remove it from the archive. Regards, -- Mehdi

Bug#807019: unison2.40.102: Segmentation fault

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

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

On 2016-01-08 11:28, Enrico Zini wrote: On Thu, Jan 07, 2016 at 09:05:51PM +0100, Mehdi Dogguy wrote: Indeed. You can also see #807019 for more information about this bug. At this point, we are stuck with no real solution (except doing massive backports). Some people copy over unison binary

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

Source: ben Version: 0.7.0 The documentation as well the templates contain http links. Those should use https instead of http.

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

Hi Enrico, On 07/01/2016 10:55, Enrico Zini wrote: > Package: unison > Version: 2.48.3-1 > Severity: important > > Hello, > > thank you for maintaining unison. > > It seems unison is not able to sync to a jessie system anymore: > Indeed. You can also see #807019 for more information about

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

Package: ftp.debian.org Severity: normal Hi, Unison 2.40 is broken now that we moved to OCaml 4.02.3 (See #807019). Please remove it from the archive. I've uploaded an updated meta-unison package which removes the dependency on this package. Regards, -- Mehdi

Bug#639910: Packaging sbt

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

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

On 2016-01-03 07:35, Christian PERRIER wrote: Quoting Philippe Cerfon (philc...@gmail.com): Package: general Severity: wishlist Tags: security Hi. I think Debian has the following two problems (or rather its security conscious users) with respect to software that gets into the system: No

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

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

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

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

Bug#803887: info ocaml fails

Hi, On 02/11/2015 23:01, Sebastien Hinderer wrote: > Package: ocaml-doc > Version: 4.02-1 > Severity: normal > > The ocaml programming manual node is listed in the dir node but it is > not possible to open it. > > The status line says: > > Cannot find node ''. > > When the package is

Bug#805456: unison: works well on my testing

Control: tags 805456 = moreinfo unreproducible Control: severity 805456 important Indeed. Works for me too. I am downgrading the severity of this bug and tagging it as "unreproducible", waiting for a reaction by the submitter. -- Mehdi

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

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 warnin

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

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

  1   2   3   4   5   6   7   8   9   10   >