Bug#1065420: RFS: ocaml-linenoise/1.5-1 [ITP] -- Lightweight readline alternative with OCaml

2024-04-23 Thread Stéphane Glondu
Dear Bo, On Mon, 4 Mar 2024 16:40:29 +0800 Bo YU wrote: I am looking for a sponsor for my package "ocaml-linenoise": Here is my review of the packaging: - There is a comment about ocaml-parany in debian/salsa-ci.yml I don't understand. - In debian/liblinenoise-ocaml.install.in, the *.cma

Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)

2024-04-15 Thread Stéphane Glondu
Hi, Le 15/04/2024 à 17:12, Bo YU a écrit : Again, I've seen this issue several times with OCaml packages, but I didn't bother to investigate. It looks like another toolchain issue, which should be fixed in a more central package, not in bisect-ppx itself. So just leave the lintian warnings as is

Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)

2024-04-14 Thread Stéphane Glondu
Dear Bo, Le 14/04/2024 à 16:30, Bo YU a écrit : I would not override dh_dwz nor dh_strip. My opinion is that what you are trying to fix are deficiencies of the toolchain that should be fixed there. First to address dh_strip issue. From what I've researched. The issue was raised by the static li

Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)

2024-04-08 Thread Stéphane Glondu
Dear Bo, Le 08/04/2024 à 17:05, Bo YU a écrit : I am looking for a sponsor for my package "bisect-ppx": [...] I've reviewed the packaging and I have a few comments. Standards-Version is not the latest. Upstream copyright years are missing in debian/copyright. A .cma file is in a "OPT:" line

Bug#770449: ITP, RFS for Caml Crush package

2014-12-12 Thread Stéphane Glondu
Le 02/12/2014 13:34, Thomas Calderon a écrit : > 1. I have split the debian-related files from the master branch. I will > now use "upstream" and "debian" branches instead. Therefore, release > tarballs will not contain this directory. $ tar tf ../caml-crush_1.0.4.orig.tar.gz|grep debian caml-crus

Bug#770449: ITP, RFS for Caml Crush package

2014-11-24 Thread Stéphane Glondu
Le 21/11/2014 13:31, Thomas Calderon a écrit : > I submitted an ITP (#770296) and an RFS (#770449) request regarding the > packaging of Caml Crush. > [...] First remarks: 1. There is a "debian" directory in the upstream tarball, is that intentional? Keep in mind that is is ignored in favour of

Bug#701706: RFS: ocamlrss/2.0-1 [ITP] -- RSS 2.0 parser and printer for OCaml

2013-05-24 Thread Stéphane Glondu
Le 24/05/2013 10:09, Prach Pongpanich a écrit : > Thanks for your review and suggestion, I have done all of the above. Your Replaces/Breaks clause is always satisfied, even in oldstable... isnt't? If so, it is pointless and you should remove it. Does ocamlrss actually install files in the same lo

Bug#701706: RFS: ocamlrss/2.0-1 [ITP] -- RSS 2.0 parser and printer for OCaml

2013-05-23 Thread Stéphane Glondu
Le 23/05/2013 05:45, Prach Pongpanich a écrit : > Packaging a new upstream 2.2.0: Sorry for taking so long, but I wanted to look at the whole thread first... which I haven't done so far. Anyway, since you've been waiting for some time now, I've just directly looked at your package without looking

Bug#662632: RFS: libaio-ocaml/1.0~rc1

2012-03-07 Thread Stéphane Glondu
Le 07/03/2012 09:52, Goswin von Brederlow a écrit : > That is what major, minor and subversions (x.y.z) are for. If I change > only something in Debian I would not increment x or y and I would not > create a new tarball for release on e.g. ocamlforge. I find this confusing. Debian has standardized

Bug#662632: RFS: libaio-ocaml/1.0~rc1

2012-03-07 Thread Stéphane Glondu
Le 07/03/2012 09:14, Goswin von Brederlow a écrit : > I really don't get that argument. Nothing in having a debian directory > in the source hinders any other distribution. And plenty of sources > contain spec files for building rpms to no detriment to Debian. If any > non rpm based distribution pi

Bug#662632: RFS: libaio-ocaml/1.0~rc1

2012-03-06 Thread Stéphane Glondu
Le 06/03/2012 15:22, Benoît Knecht a écrit : > I think it important for any maintainer to clearly differentiate in > their mind upstream from Debian, even if they happen to be the same > person. Otherwise, you're artificially limiting your software to Debian, > which is at the opposite side of what

Bug#662632: RFS: libaio-ocaml/1.0~rc1

2012-03-05 Thread Stéphane Glondu
Le 05/03/2012 12:33, Goswin von Brederlow a écrit : > I am looking for a sponsor for my package "libaio-ocaml" I've looked at the git repository (037a448). It is written explicitly in [1]: "Do not close RFS bugs in debian/changelog." but the bug you refer to in debian/changelog is a RFS bug

Re: RFS: proofgeneral

2012-01-13 Thread Stéphane Glondu
Le 13/01/2012 08:59, Hendrik Tews a écrit : >Done and uploaded. The new version should appear soon. > > debian.mentors dropped my upload from yesterday evening. But now > the package is there. Uploaded to Debian. Thank you for your contribution! -- Stéphane -- To UNSUBSCRIBE, email to de

Re: RFS: proofgeneral

2012-01-12 Thread Stéphane Glondu
Le 12/01/2012 21:52, Hendrik Tews a écrit : >For now I moved the package to non-free, see the latest instance >on mentors.debian. > > There was a prerelease this evening, containing the license > change. I've just uploaded a new package, which is now in section > main again. Great! You sh

Re: RFS: proofgeneral

2012-01-11 Thread Stéphane Glondu
Le 11/01/2012 14:13, Hendrik Tews a écrit : >I've just noticed that there are files under CC-BY-NC-SA-3. > > Upstream has just changed the license to CC-BY-SA-3, see > http://www4.in.tum.de/~wenzelm/cgi-bin/repos.cgi/ProofGeneral/file/be73425fbe77/images/README > > Therefore the issue is pro

Re: RFS: proofgeneral

2012-01-10 Thread Stéphane Glondu
Le 10/01/2012 15:56, Hendrik Tews a écrit : > - in debian/changelog, there are two extraneous blank lines after the > first entry; don't do that > > Done. I was talking about the lines *between* changelog entries, not inside the last one. > - consider using http://dep.debian.net/de

Re: RFS: ocaml-fdinfo

2011-10-25 Thread Stéphane Glondu
Le 25/10/2011 16:00, Nicolas Dandrimont a écrit : > I'm Cc:'ing the OCaml Team which may be interested in your package. I'll > try to take a look tonight, unless someone beats me to it. Thank you for bringing this to our attention. >> I am looking for a sponsor for my package "ocaml-fdinfo". >> >

Re: RFS: dojo

2009-09-02 Thread Stéphane Glondu
Jason Morawski a écrit : > The source package is named "dojo" and the binary package produced is > named "jslib-dojo". This follows the naming scheme used by the other > jslib packages. However, if the naming policy has changed regarding > these types of packages, I will be more than happy to oblig

Re: looking for sponsor for a non-free package

2009-07-11 Thread Stéphane Glondu
Harald Dunkel a écrit : > I have a question, anyway: The game is supposed to build and > work on all platforms, but I can build it only for i386 and > amd64. Are non-free packages built for the other platforms > automagically? Or would you suggest to restrict the list of > platforms? See: http://

Re: Not RFS: febootstrap (ITP #530425)

2009-05-26 Thread Stéphane Glondu
Richard W.M. Jones a écrit : > filelight is useful to find out which parts of the filesystem are > consuming too much space. [...] > However filelight is a very large dependency (pulls in large > parts of KDE + X11) so it's only a suggestion. What about suggesting filelight | gnome-utils, then? gn

Re: dch multi-maintainer mode

2009-04-21 Thread Stéphane Glondu
Neil Williams a écrit : >> Is it still allowed as per 3.8.1 policy to use multi maintainer style >> changelogs? > > Yes. And what was the prevous style of changelog allowed, by the way? -- Stéphane -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscr

Re: Forcing version on dependency, how?

2009-03-14 Thread Stéphane Glondu
Jean-Yves Avenard a écrit : > Is there a way to force which version of the dependency is going to be > installed? > Like right now, my package automatically add a dependency to version > 1.0.19 of the library, I want that dependency to be on version 1.0.17 I think your approach is wrong. You shoul