Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: ocamlformat
Version : 0.26.2
Upstream Contact: Tarides
* URL : https://github.com/ocaml-ppx/ocamlformat
* License
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: ocaml-version
Version : 3.6.7
Upstream Contact: Anil Madhavapeddy
* URL : https://github.com/ocurrent/ocaml
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: 0install-solver
Version : 2.18
Upstream Contact: Thomas Leonard
* URL : https://github.com/0install/0install
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: opam-0install-cudf
Version : 0.4.3
Upstream Contact: Thomas Leonard
* URL : https://github.com/ocaml-opam/opam
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: ocaml-spdx-licenses
Version : 1.2.0
Upstream Contact: Kate
* URL : https://github.com/kit-ty-kate/spdx_licenses
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: ocaml-swhid-core
Version : 0.1
Upstream Contact: OCamlPro
* URL : https://github.com/ocamlpro/swhid_core
* License
Hi,
Le 13/08/2024 à 12:15, julien.pu...@gmail.com a écrit :
And of course, this is where I came to my wits' end: I can compile the
new elpi successfully... but I have no way to install this new elpi
binary packages in the schroot to test it against different coq-elpi!
This is a situation I've
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: ocaml-digestif
Version : 1.2.0
Upstream Contact: Eyyüb Sari and Romain Calascibetta
* URL : https://github.com
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: ocaml-ohex
Version : 0.2.0
Upstream Contact: Hannes Mehnert
* URL : https://opam.ocaml.org/packages/ohex/
* License
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: ocaml-intrinsics-kernel
Version : 0.17.1
Upstream Contact: Jane Street developers
* URL : https://github.com
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: ocaml-kdf
Version : 1.0.0
Upstream Contact: Alfredo Beaumont, Hannes Mehnert
* URL : https://github.com/robur-coop
ill take care of this package, with Vincent's agreement and sponsorship.
Cheers,
--
Stéphane Glondu
signature.asc
Description: OpenPGP digital signature
Wouter Verhelst a écrit :
>>> Ah, so this is about not interfering with testing migration, I guess?
>> It's not only testing migration. As an example: If you have a large chain
>> of binNMUs which all need some dep-wait on a package upper in the chain
>> you get the effect that the whole thing tak
Gabor Gombas a écrit :
> That won't work if upstream wants to support OSes other than Linux. My
> memory is getting hazy but I had to use the same technique in the past
> because not all OSes are capable of letting plugins resolve symbols from
> the main binary, at least not without extra complicat
Julien Cristau a écrit :
> FWIW, I'm not going to use something that I can't produce with git
> format-patch and feed to git send-email / git am since that feels like
> busy work; in particular the Author and Description fields are not
> needed given there's From and Subject with the same informati
Andreas Tscharner a écrit :
>> On the other hand, Section 10.4 says only "the script name should not
>> include an extension". So you can leave the extension for
>
> What is the intention of this rule anyway?
So I'm not the only one to wonder about this.
After digging I've found the following d
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: obus
Version : 1.0~rc1
Upstream Author : Jérémie Dimino
* URL : http://obus.forge.ocamlcore.org/
* License : BSD
Programming Lang: OCaml
Description : pure OCaml impl
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: ocaml-usb
Version : 0.1
Upstream Author : Jérémie Dimino
* URL : http://ocaml-usb.forge.ocamlcore.org
* License : BSD-C3
Programming Lang: C, OCaml
Description : OCam
Notch-1 a écrit :
> Installing debian etch on several computers and with 5 different kernels
> (2.6.15, 18, 22, 24 and 25) i found out that it's impossible to mount fixed
> drives
> (with any partition type) by clicking on them in konqueror media:/, do you
> know about this problem?
> I got "h
It seems that some people had a problem similar, and solved it.
Anyway, this is definitely not the right place to ask your question.
Probably a mailing-list from there:
http://lists.debian.org/users.html
would be more suitable. I forward this bugreport to konqueror.
Cheers,
--
Stéphane Glondu
Carlo Segre a écrit :
> 2. the ifeffit source package is contrib and cannot be built by the
> autobuilders because of its build time dependence on pgplot5.
>
> The latter is causing me much grief and needs to be solved before I work
> on consistency issues. Right now I have to build the package b
Raphael Hertzog a écrit :
> Note that the lintian message specifically requests to contact us if you
> decide to stick with 1.0 for such a technical reason. That's done that way
> so that I can help resolve those problems. No later than this morning I
> contacted the launchpad guys to allow new sou
Raphael Hertzog a écrit :
>>> Preparing the transition in experimental is not always done and takes
>>> much more energy than such a system would take.
>> Why, actually?
>
> I don't an exhaustive answer but here are some points:
> 1/ you can't request bin-nmus of reverse-dependencies in experiment
Neil Williams a écrit :
> I did a form of that for Emdebian Crush (emrecent) which used
> edos-debcheck to see if the upload was going to break the repository
> prior to making the upload. [...]
Hum... interesting. If an upload is going to break the repository, dak
could indeed ask some kind of co
Yves-Alexis Perez a écrit :
> And you usually need root access for invoke-rc.d or /etc/init.d scripts
> (unless you have some kind of specific sudo permissions for that). So
> you might be able to kill other process as well.
I guess one (be it a human operator or a monit-like daemon) can be
easily
Le 10/08/2010 12:18, Stanislav Maslovski a écrit :
> Not just to repair. First of all, / must have enough tools to
> bring the system up to the point where the other file systems can be
> mounted (i.g., over the network).
Is this still relevant, now that we have initrd?
> This is an unfortunate c
Le 20/08/2010 18:58, W. Martin Borgert a écrit :
> I just tried to not creating the .orig.tar.gz for a package
> with version number 0.1+23-1, but dpkg-buildpackage creates
> it, ignoring my "-sd" suggestion. Are there any known
> problems or traps with this option? TIA.
It seems that "-sd" only a
Le 07/09/2010 11:37, Holger Levsen a écrit :
apt-cache show sendfile gerstensaft
It seems to use its own protocol and needs special software on both
sides. On the other hand, wget or curl is installed on all systems...
and HTTP works also for non-Linux systems.
--
Stéphane
--
To UNSUBSCRI
Le 16/09/2010 09:22, Josselin Mouette a écrit :
> I agree this is a cleaner solution, but how do you ensure there are
> sources (deb-src) referenced in the sources.list ?
You don't need to. The package would be reported as uninstallable. Some
message suggesting to add deb-src lines to sources.list
Le 24/09/2010 22:44, Dmitry E. Oboukhov a écrit :
> If this package is built it wants more than one gigabyte (~1.2-1.4G)
> RAM to build. So there are two buildd servers can't build
> *architecture:all* packages. So this package can't pass into testing
> for a long time (more than 120 days).
What
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: aac-tactics
Version : 0.1
Upstream Author : Thomas Braibant, Damien Pous
* URL : http://sardes.inrialpes.fr/~braibant/aac_tactics/
* License : LGPL-3+
Programming Lang:
Le 15/01/2011 08:37, Tollef Fog Heen a écrit :
> This would also purge the configuration of packages where I have no wish
> to do so. I sometimes uninstall packages without purging them, just
> because I want to keep the configuration around.
If you are so concerned about your configuration files
Le 15/01/2011 01:40, Roger Leigh a écrit :
> Yes, and this is what I did. It's just rather tedious to (IIRC)
> repeatedly run "dpkg-reconfigure sysv-rc" and then find out which file
> is offending, run "dpkg -S $file", and then purge it. Because the error
> message only lists the first offending
Le 15/01/2011 01:05, Roger Leigh a écrit :
> This is mostly due to removed packages which need fully purging to
> remove the last traces of old init scripts which break the process.
I've already experienced issues with configuration files from
uninstalled packages lying around. It wasn't with inss
Le 15/01/2011 11:29, Philipp Kern a écrit :
> Arch:all binNMUing will only work if you keep the invariant of
> version(arch:all) = version(source) in some way.
Why is this needed?
--
Stéphane
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tro
Le 15/01/2011 13:23, Julien Cristau a écrit :
> Package: foo
> Architecture: all
>
> Package: bar
> Architecture: any
> Depends: foo (= ${source:Version})
>
> If ${source:Version} is not version(arch:all) you've got yourself an
> uninstallable package. If ${source:Version} is not version(source)
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: js-of-ocaml
Version : 1.0
Upstream Author : Jérôme Vouillon
* URL : http://ocsigen.org/js_of_ocaml/
* License : LGPL-2+
Programming Lang: OCaml, JavaScript
Description
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: ocaml-cil
Version : 1.3.7
Upstream Author : George C. Necula and others
* URL : http://sourceforge.net/projects/cil/
* License : BSD
Programming Lang: OCaml
Description
Le 06/03/2011 11:12, Lucas Nussbaum a écrit :
> In the pkg-ruby-extras team, we are considering switching from
> svn-buildpackage to git.
>
> Does someone has feedback on this switch, in the context of teams
> maintaining many small packages?
We did that a few years back in the OCaml team, and it
Le 15/01/2011 18:22, Steve Langasek a écrit :
[...] and require us to use a hackish (>= ), (<< )
construction for all arch:any -> arch:all dependencies just as we already
have to do for arch:all -> arch:any dependencies.
This is as "wrong" as adding artificial versioned build-dependencies, a
Reinhard Tartler a écrit :
>> Not completely. If you have the tarballs of the released versions you
>> can import and merge them.
>
> can you point me to someone (or ideally to a script or detailed
> explanation) that managed to do that in an automated way?
We did that inside the OCaml team to mi
Hello Goswin,
Goswin von Brederlow a écrit :
> I recently converted a few quilt using local packages to the new 3.0
> (quilt) format. Additionaly those packages are kept in an RCS
> (mercurial here). Now the problem is: How to version control them?
> [...]
You might be interested by [1]...
[1] h
Marco d'Itri a écrit :
> I know that Debian supports this, but I also know that maintaning
> forever large changes to packages for no real gain sucks.
Could you elaborate on the kind of "large changes" there are in Debian
to support this?
> A partial list of invalid reasons is: [...]
How about:
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: ocaml-ipaddr
Version : 1.0.0
Upstream Author : David Sheets, Anil Madhavapeddy, Hugo Heuzard
* URL : https://github.com/mirage/ocaml-ipaddr
* License : ISC
Programming L
Le 26/04/2012 19:02, Raphael Geissert a écrit :
> Timo Juhani Lindfors wrote:
>> True. We need to both fix the RNG and use a longer moniker.
>
> M = H(CRYPT_PRNG())
>
> for example:
>
> use Digest::SHA qw(sha1_hex);
>
> open(UR, '<', '/dev/urandom') or die($!);
>
> my $rbytes;
> die if (sysrea
Le 19/06/2012 16:20, Alastair McKinstry a écrit :
> While i'm still investigating, _something_ in the sid environment is the
> real culprit and
> I can't assign a bug to it yet until I pin it down. Has anyone seen a
> similar issue elsewhere,
> or got a hint as to how to handle it? I want to make
Le 17/08/2012 13:08, Andreas Tille a écrit :
> So we finally have three independently developed solutions (we also have
> several instances of a debian/get-orig-source script in Debian Med
> team) and my suggestion was just to settle with a common and simple
> solution. This should be pretty simpl
Le 05/09/2012 22:11, Andreas Tille a écrit :
>>> So we finally have three independently developed solutions (we also have
>>> several instances of a debian/get-orig-source script in Debian Med
>>> team) and my suggestion was just to settle with a common and simple
>>> solution. This should be pret
Le 13/05/2013 15:51, Paul Wise a écrit :
> [...] as long
> as there is a way to build-depend on the build-dependencies for a
> source package, that should be fine. As a bonus we can get rid of
> mk-build-deps :)
How so?
--
Stéphane
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian
Le 16/05/2013 07:05, Eugene Zhukov a écrit :
> I'm trying to download sources using d/watch and uscan. Here is the
> output of uscan --verbose --force-download:
> -- Scanning for watchfiles in .
> -- Found watchfile in ./debian
> -- In debian/watch, processing watchfile line:
>https://www.saxon
Le 16/05/2013 05:04, Philip Hands a écrit :
> Do you have any thoughts on how that compares with using
> BrowserID/Persona? I'd got the impression that BrowserID has been put
> together learning from mistakes of OpenID & WebID, but perhaps I'm just
> swallowing their marketing.
IIUC, there is no
Le 16/05/2013 18:37, Russ Allbery a écrit :
>>> You could, in theory, switch to DNSSEC, but now you're just replacing
>>> one CA cartel with another.
>
>> Except that with DNSSEC (and DANE), the number of people you have to
>> trust is much smaller.
>
> Right, it depends on what your risk model i
Le 16/05/2013 20:40, Russ Allbery a écrit :
> What am I missing?
>
> I suppose one thing that I could be missing is that, with a certificate,
> you have no privacy controls over what metadata you release. Whatever you
> put in the certificate is visible to anyone who looks at the certificate.
> (
Le 17/05/2013 13:50, Simon McVittie a écrit :
> According to libtool documentation, on some platforms this distinction
> is really significant, and "real shared libraries" can't be
> dlopen()'d. However, GNU/anything and Windows (and also Mac OS, I
> think) are among the platforms where either work
Le 17/05/2013 14:18, Sune Vuorela a écrit :
> On 2013-05-17, Simon McVittie wrote:
>> dlopen()'d. However, GNU/anything and Windows (and also Mac OS, I
>> think) are among the platforms where either works, so in practice most
>
> You can't link plugins on windows, I'm told.
Indeed. Some informat
Le 17/05/2013 15:45, Chow Loong Jin a écrit :
But how do you load a plugin without using dlopen()?
> [...]
> Okay, so real shared libraries can't be dlopen()'d on some systems, and
> plugins
> still have to be dlopen()'d. That doesn't answer my question, really.
It kind of does, actually :-)
Le 17/05/2013 17:43, Russ Allbery a écrit :
> [...]
> 4. Hijack that metadata identity request so that it goes to their server
>instead of mine. This can be done in any number of ways (DNS cache
>poisoning, compromise of www.eyrie.org, compromise of my account on
>www.eyrie.org, TCP ac
Le 07/07/2013 08:39, Scott Leggett a écrit :
>> you may not (and you may not permit anyone else to) copy, modify,
>> create a derivative work of, reverse engineer, decompile or
>> otherwise attempt to extract the source code of the Software or any
>> part thereof, unless this is expressly permitte
[CC-ing debian-devel to get more opinions]
On 10/06/2011 04:07 PM, Jonathan Nieder wrote:
>> ocamlbuild's logic is definitively incorrect, but I'm not sure if dash's
>> new behaviour is correct. "bash -c" doesn't skip fork() when a
>> redirection is set up, I guess for a reason. "dash -c" should p
Le 13/12/2011 21:30, Philipp Kern a écrit :
> But then I don't see how you could avoid circular build-dependencies
> with compilers written in their own language. fpc/fp-compiler does the
> same.
OCaml, F# (and Scala, it seems) do that by targetting a bytecode for
which there exists an independen
Le 30/03/2012 08:18, Tollef Fog Heen a écrit :
> I doubt you'll get upstreams to write metainit files. I think we'll
> have upstreams providing systemd files and so I think metainit will
> basically be #15 in http://xkcd.com/927/.
Actually, it's more systemd that looks like #15.
Cheers,
--
St
Le 18/04/2013 12:07, Marc Haber a écrit :
>> The tool you are looking for is "mk-build-deps" from the package
>> "devscripts".
>
> So one uses mk-build-deps to create a .deb containing the build
> dependencies as binary dependencites, put that .deb into an local
> aptable archive, run apt-get upd
Le 18/04/2013 16:41, Matthias Klose a écrit :
> So what is the status for some runtimes/interpreters (would like to see some
> follow-up/corrections from package maintainers)?
> [...]
> - Lua, Ocaml, Haskell, Guile, ... ?
First, let me explain a few notions that will be useful to grasp the
situat
Le 05/05/2013 03:50, Adam Borowski a écrit :
> On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:
>> As far as bootstrapping is concerned, the OCaml sources include
>> precompiled (bytecode) executables that are used in a first stage of the
>> build process (i.e
Le 11/05/2013 20:05, Aron Xu a écrit :
> An easy example is that, on Solaris, there is a something called boot
> environment (BE), which is essentially snapshots of the combination of
> /usr and /boot, users can switch between different BEs easily without
> affecting any user data. Without /usr mer
Le 14/06/2013 15:19, Timo Juhani Lindfors a écrit :
>> This doesn't really help when trying to diagnose things, and even for
>> successful
>> builds it's valuable to have the complete build log, including the parts how
>> the
>> upstream build system is called from the Debian packaging.
>
> This
Le 28/11/2013 21:52, Niels Thykier a écrit :
>> I've found the builds on the less used architectures have been useful
>> for flushing out unusual bugs, particularly when the code ships with
>> many test cases and it exposes problems for big endian machines, etc.
>>
>> Also, kFreeBSD and HURD are bo
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
Control: block 731528 with -1
* Package name: camldbm
Version : 1.0
Upstream Author : INRIA
* URL : https://forge.ocamlcore.org/projects/camldbm/
* License : LGPL
Programming Lang
Le 15/12/2013 13:03, Niels Thykier a écrit :
>>> Keeping them around is different from them being considered as release
>>> architectures (or even just keeping them in testing). Keeping these
>>> architectures in testing do involve a burden, like blocking testing
>>> migration when they FTBFS[1].
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: optcomp
Version : 1.5
Upstream Author : Jérémie Dimino
* URL : https://github.com/diml/optcomp
* License : BSD
Programming Lang: OCaml
Description : syntax extension fo
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: ocaml-ctypes
Version : 0.2.3
Upstream Author : Jeremy Yallop
* URL : https://github.com/ocamllabs/ocaml-ctypes
* License : Expat
Programming Lang: C, OCaml
Description : library
Le 28/03/2014 08:23, Matt Grant a écrit :
> One thing that put me off ifupdown quite some time ago was finding that
> configured bridges made NFS client mounts on the host wait... who would
> implement a bridge with interface listen/wait/STP functionality on a
> pure work station or server? Sounds
Le 01/05/2011 15:34, Andreas Barth a écrit :
> 1. How to push from a vcs (git, svn, ...) to ppa? (This should be
> coordinated with ftp-masters, so that the same method could be used
> later on for uploading into unstable.)
>
> 2. How could we create new ppa repositories easy enough, how do we
> h
Le 01/05/2011 17:16, Andreas Barth a écrit :
>> I don't understand why this is only point 5. Setting up a custom
>> repository easily usable is quite easy... and done already
>> (mozilla.debian.net has been mentioned; I also happen to provide
>> unofficial packages on ocaml.debian.net).
>
> It's e
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: tyxml
Version : 1.91
Upstream Author : Thorsten Ohl, Vincent Balat, and others
* URL : http://ocsigen.org/tyxml/install
* License : LGPL
Programming Lang: OCaml
D
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: ocaml-config-file
Version : 1.0
Upstream Author : Maxence Guesdon
* URL : http://config-file.forge.ocamlcore.org/
* License : LGPL-2+
Programming Lang: OCaml
Description
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: lablgtk-extras
Version : 1.0
Upstream Author : Maxence Guesdon
* URL : http://gtk-extras.forge.ocamlcore.org/
* License : LGPL-2+
Programming Lang: OCaml
D
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: nproc
Version : 0.5.1
Upstream Author : MyLife
* URL : https://github.com/MyLifeLabs/nproc
* License : BSD-3-clause
Programming Lang: OCaml
Description : pr
Le 10/02/2015 19:16, Evgeni Golov a écrit :
>> * Package name: nproc
>
> not sure this is relevant, but there is /usr/bin/nproc in pkg:coreutils.
> This might be confusing for users.
"nproc" as source package name is free. The binary package will be
libnproc-ocaml-dev.
Cheers,
--
Stéphane
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: camlp4
Version : 4.02.1+2
Upstream Author : Inria
* URL : https://github.com/ocaml/camlp4
* License : LGPL-2
Programming Lang: OCaml
Description : Pre Processor Pret
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: labltk
Version : 8.06.0
Upstream Author : Inria
* URL : https://forge.ocamlcore.org/projects/labltk/
* License : LGPL
Programming Lang: C, OCaml
Description : OCaml b
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: ppx-tools
Version : 0.99.2
Upstream Author : Alain Frisch, LexiFi
* URL : https://github.com/alainfrisch/ppx_tools
* License : MIT
Programming Lang: OCaml
Description :
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu"
* Package name: uutf
Version : 0.9.4
Upstream Author : Daniel C. Bünzli
* URL : http://erratique.ch/software/uutf
* License : BSD
Programming Lang: OCaml
Description : UTF streaming co
Le 20/07/2015 18:46, Ian Jackson a écrit :
> AFAICT the only tools which attempt to convert between a `3.0 (quilt)'
> and a series of git commits are git-dpm and gbp-pq. Am I wrong about
> that ?
There are also dom-{apply,save}-patches in dh-ocaml. They are basically
wrappers around git-am and gi
Hi,
It has been brought to my attention that both packages "whitedune" and
"dune" provide the binary "/usr/bin/dune" (#916468).
The situation falls directly under section 10.1 of the Policy:
https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries
> Two different packages must not inst
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: ocaml-num
Version : 1.2
Upstream Author : Xavier Leroy
* URL : https://github.com/ocaml/num/
* License : LGPL 2.1 with OCaml linking exception
Programming Lang: OCaml, C
Description
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: ocaml-sexplib0
Version : 0.12.0
Upstream Author : Jane Street Group, LLC
* URL : https://github.com/janestreet/sexplib0
* License : MIT
Programming Lang: OCaml
Description
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: janest-base
Version : 0.12.2
Upstream Author : Jane Street Group, LLC
* URL : https://github.com/janestreet/base
* License : MIT
Programming Lang: OCaml
Description : Full
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: ocaml-stdio
Version : 0.12.0
Upstream Author : Jane Street Group, LLC
* URL : https://github.com/janestreet/stdio
* License : MIT
Programming Lang: OCaml
Description : Standard IO
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: ocaml-integers
Version : 0.3.0
Upstream Author : Jeremy Yallop and others
* URL : https://github.com/ocamllabs/ocaml-integers
* License : MIT
Programming Lang: OCaml
Description
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: ppxlib
Version : 0.8.1
Upstream Author : Jane Street Group, LLC
* URL : https://github.com/ocaml-ppx/ppxlib
* License : MIT
Programming Lang: OCaml
Description : meta-programming
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: janest-ocaml-compiler-libs
Version : 0.12.0
Upstream Author : Jane Street Group, LLC
* URL : https://github.com/janestreet/ocaml-compiler-libs
* License : Apache-2.0
Programming Lang
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: ocaml-mmap
Version : 1.1.0
Upstream Author : Jérémie Dimino and Anton Bachin
* URL : https://github.com/mirage/mmap
* License : LGPL 2.1 with linking exception
Programming Lang: OCaml
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: ocaml-stdcompat
Version : 10
Upstream Author : Thierry Martinez
* URL : https://github.com/thierry-martinez/stdcompat
* License : BSD
Programming Lang: OCaml
Description
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
User: debian-ocaml-ma...@lists.debian.org
Usertags: ocaml-4.08-transition
* Package name: ppxfind
Version : 1.3
Upstream Author : Jérémie Dimino
* URL : https://github.com/diml/ppxfind
* License : BSD
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: ocaml-charinfo-width
Version : 1.1.0
Upstream Author : ZAN DoYe
* URL : https://bitbucket.org/zandoye/charinfo_width/
* License : MIT
Programming Lang: OCaml
Description
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: ocplib-endian
Version : 1.0
Upstream Author : Pierre Chambart
* URL : https://github.com/OCamlPro/ocplib-endian
* License : LGPL-2.1
Programming Lang: OCaml
Description : optimised
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
* Package name: lwt-log
Version : 1.1.1
Upstream Author : Shawn Wagner and Jérémie Dimino
* URL : https://github.com/ocsigen/lwt_log
* License : LGPL-2.0+
Programming Lang: OCaml
Description : Lwt
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: not-ocamlfind
Version : 0.10
Upstream Contact: Chet Murthy
* URL : https://github.com/chetmurthy/not-ocamlfind
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org
* Package name: camlp5-buildscripts
Version : 0.02
Upstream Contact: Chet Murthy
* URL : https://github.com/camlp5/camlp5
1 - 100 of 192 matches
Mail list logo
