Bug#1075934: ITP: ocamlformat -- auto-formatter for OCaml code
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 : MIT Programming Lang: OCaml Description : auto-formatter for OCaml code ocamlformat is a code formatter for OCaml. It comes with opinionated default settings but is also fully customizable to suit your coding style. - Profiles: ocamlformat offers profiles with predefined formatting configurations. - Configurable: Users can change the formatting profile and configure every option in their .ocamlformat configuration file. - Format Comments: ocamlformat can format comments, docstrings, and even code blocks in your comments. - RPC: ocamlformat provides an RPC server that can be used by other tools to easily format OCaml Code. This package will be maintained in the OCaml team.
Bug#1075935: ITP: ocaml-version -- handle OCaml compiler version strings
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-version * License : ISC Programming Lang: OCaml Description : handle OCaml compiler version strings This library provides facilities to parse version numbers of the OCaml compiler, and enumerates the various official OCaml releases and configuration variants. This package is a dependency of ocamlformat. It will be maintained in the OCaml team.
Bug#1076364: ITP: 0install-solver -- package dependency solver
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 * License : LGPL-2.1 Programming Lang: OCaml Description : package dependency solver A package dependency resolver based on a SAT solver. This was originally written for the 0install package manager, but is now generic and is also used as a solver backend for opam. The SAT solver is based on MiniSat (http://minisat.se/Papers.html) and the application to package management is based on OPIUM (Optimal Package Install/Uninstall Manager). 0install-solver uses a (novel?) strategy to find the optimal solution extremely quickly (even for a SAT-based solver). This package is a new transitive dependency of opam. It will be maintained in the OCaml Team.
Bug#1076365: ITP: opam-0install-cudf -- Opam solver using 0install backend using the CUDF interface
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-0install-solver * License : ISC Programming Lang: OCaml Description : Opam solver using 0install backend using the CUDF interface Opam's default solver is designed to maintain a set of packages over time, minimising disruption when installing new programs and finding a compromise solution across all packages. . In many situations (e.g. CI, local roots or duniverse builds) this is not necessary, and we can get a solution much faster by using a different algorithm. . This package uses 0install's solver algorithm with opam packages using the CUDF interface. This package is a new dependency of opam. It will be maintained in the OCaml Team.
Bug#1076366: ITP: ocaml-spdx-licenses -- library providing a strict SPDX License Expression parser
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 * License : MIT Programming Lang: OCaml Description : library providing a strict SPDX License Expression parser An OCaml library aiming to provide an up-to-date and strict SPDX License Expression parser. It implements the format described in: https://spdx.github.io/spdx-spec/appendix-IV-SPDX-license-expressions/ See https://spdx.org/licenses/ for more details. This package is a new dependency of opam. It will be maintained in the OCaml Team.
Bug#1076367: ITP: ocaml-swhid-core -- OCaml library to work with swhids
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 : ISC Programming Lang: OCaml Description : OCaml library to work with swhids swhid_core is an OCaml library to with with Software Heritage persistent identifiers (swhids). This is the core library, for most use cases you should use the swhid library instead. This package is a new dependency of opam. It will be maintained in the OCaml Team.
Re: Porterbox - impossible efficient debugging?
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 found myself quite often, too. BTW, IIUC, it is be possible with namespaces to give root privileges (or enough to install packages) to anybody inside a container. [1] could be a way, but it needs unprivileged user namespaces. But I understood that DSA was reluctant to enable unprivileged user namespaces on Debian machines because of security concerns... Couldn't an exception be made for porterboxes? After all, these are dedicated to porting and nothing sensitive should be done there. [1] https://lists.debian.org/msgid-search/20240625081620.ga1354...@subdivi.de I'm quite fond of the single-page just-follow-the-steps tutorial: https://dsa.debian.org/doc/schroot/ hence my dream is to be able to do something like the following to get not only a cross-compilation but also cross-running through whatever virtual system (say provided by a dd-cross-schroot package) : [...] Actually, you can achieve something similar with qemu-user(-static), binfmt and pbuilder: sudo pbuilder create --basetgz sid-ppc64el.tgz \ --distribution sid --debootstrapopts --variant=minbase \ --architecture ppc64el sudo pbuilder login --basetgz sid-ppc64el.tgz Of course, that wouldn't be as good as an actual box of the right architecture, but it would definitely help getting many problems solved. As you may have noticed from the above I'm quite clueless on how schroot and cross-compilation work - and to be honest, I'd like to stay so as I have other itches to scratch and hopefully other areas of expertise - but I'm hopeful others have the competence and the will to provide solutions. Keep in mind that the solution above remains emulation and I've already faced situations where behaviour differed with actual hardware. That being said, it helped me a lot in debugging packages on exotic architectures. Cheers, -- Stéphane
Bug#1078675: ITP: ocaml-digestif -- hashes implementations
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/mirage/digestif * License : MIT Programming Lang: OCaml, C Description : hashes implementations Digestif is a toolbox to provide hashes implementations in C and OCaml. It uses the linking trick and user can decide at the end to use the C implementation or the OCaml implementation. . It provides implementation of: * MD5 * SHA1 * SHA224 * SHA256 * SHA384 * SHA512 * SHA3 * Keccak-256 * WHIRLPOOL * BLAKE2B * BLAKE2S * RIPEMD160 This package is a new dependency of ocaml-ca-certs and will be maintained in the OCaml team.
Bug#1078789: ITP: ocaml-ohex -- OCaml library for hexadecimal encoding and decoding
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 : BSD-2-clause Programming Lang: OCaml Description : OCaml library for hexadecimal encoding and decoding ohex is an OCaml library to encode and decode hexadecimal byte sequences. This package is a new dependency of ocaml-ca-certs. It will be maintained in the OCaml team.
Bug#1079269: ITP: ocaml-intrinsics-kernel -- a library of intrinsics for 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: ocaml-intrinsics-kernel Version : 0.17.1 Upstream Contact: Jane Street developers * URL : https://github.com/janestreet/ocaml_intrinsics_kernel * License : MIT Programming Lang: OCaml, C Description : a library of intrinsics for OCaml The ocaml_intrinsics_kernel library provides an OCaml interface to operations that have dedicated hardware instructions on some micro-architectures. Currently, it provides the following operations: . * conditional select . ocaml_intrinsics_kernel can be used by programs compiled to javascript. This package is a new dependency of janest-base. It will be maintained in the OCaml team.
Bug#1081257: ITP: ocaml-kdf -- key derivation functions in 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: ocaml-kdf Version : 1.0.0 Upstream Contact: Alfredo Beaumont, Hannes Mehnert * URL : https://github.com/robur-coop/kdf * License : BSD-2-Clause Programming Lang: OCaml Description : key derivation functions in OCaml A pure OCaml implementation of scrypt, PBKDF 1 and 2 as defined by PKCS#5, and HKDF. This package is a new dependency of ocaml-x509. It will be maintained in the OCaml team.
Re: ecki is retiring (Debian RT)
owner 486000 ! thanks Vincent Bernat wrote: >> net-acct -> can probably be removed from distribution? > > I know that it is widely used in some places despite the existence of > better solutions. I prefer to adopt it instead of letting it getting out > of Debian. I will take care of this package, with Vincent's agreement and sponsorship. Cheers, -- Stéphane Glondu signature.asc Description: OpenPGP digital signature
Re: The wider implications of debhelper/dbus breakage
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 takes several days just because >> each step of the chain first blocks on signing and uploading once a day to >> do the next one. > > How often does that happen? (serious question, I have no clue) I will speak with my OCaml maitainer's hat, but what I say is not really specific to OCaml. For example, each OCaml transition involve rebuilding a lot of packages (about 139), with 6 levels of dependencies. So if some build takes 2 days or more (for the current transition, on some builds, it was even more than a week) to be uploaded, it means that transition will last at least 12 days (for the current transition, all packages were rebuilt/uploaded/installed after 21 days). But most of the builds are successful (and fast). If packages were automatically uploaded on success, a dependency level would be cleared at each dinstall run, meaning the whole recompilation would take less than 2 days. Now, imagine that during this transition, another long transition (for another library) starts... The new transition can be entangled with the first one, delaying it even further. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: shared library in binary-package?
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 complications. Do you have an example of such OS that is likely to be supported by freesmartphone.org ? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
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 information. +1 -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What is this rule for?
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 discussion: http://lists.debian.org/debian-policy/2003/04/msg00031.html which led to the following bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190753 which was fixed in version debian-policy/3.7.0.0. I agree with the arguments, but I am not convinced we should diverge from upstream on this topic, by the way. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550754: ITP: obus -- pure OCaml implementation of DBus
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 implementation of DBus OBus is a pure OCaml implementation of DBus. It aims to provide a clean and easy way for OCaml programmers to access and provide DBus services. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#552366: ITP: ocaml-usb -- OCaml bindings to libusb-1.0
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 : OCaml bindings to libusb-1.0 OCaml-USB is a binding to libusb-1.0, a userspace USB programming library. It uses Lwt to ease use of asynchronous IO features of libusb-1.0. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#492231: general: unable to mount fixed drives
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 "hal-storage-fixed-mount-all-options refused uid 500" when i click on a > fixed > hard-disk, or right-click and then "mount", same thing... > No problem with konqueror as root (yes i am in plugdev group, but still...). > No problem with removable devices (pen or hard-disks). > No problem with manual mount, after it i'm able to use konqueror media:/, but > still can't do unmount... Are you in "disk" group? Can you mount the disks with pmount (as non-root)? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492231: general: unable to mount fixed drives
reassign 492231 konqueror severity 492231 normal thanks Notch-1 wrote: > 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 "hal-storage-fixed-mount-all-options refused uid 500" when i click on a > fixed > hard-disk, or right-click and then "mount", same thing... > No problem with konqueror as root (yes i am in plugdev group, but still...). > No problem with removable devices (pen or hard-disks). > No problem with manual mount, after it i'm able to use konqueror media:/, but > still can't do unmount... Have you tried typing "hal-storage-fixed-mount-all-options" on Google? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming policy for Perl modules (mass bug filing)
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 by hand on > whatever architectures I can get my hands on (I only have 8) and upload > all the binaries. The package has not migrated to testing for nearly 2 > years because not all the architectures are present and until this is > resolved, there is really no point since it will only languish in unstable. Why didn't you just ask removal of binary packages on architectures that lack up-to-date packages? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ba9d6a2.6060...@glondu.net
Re: About new source formats for packages without patches
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 source formats in karmic PPA > because one DD continued to use 1.0 for this reason. Did they reply? AFAIC, the same applies to jaunty PPA and lenny-backports. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bac70ea.6020...@glondu.net
Re: Serializing transitions
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 experimental >(to verify that all packages build fine with the updated package, and >that's one of the main task in preparing the transition) > 2/ you have to manually reupload a new source package to unstable with all >the delay it induces for getting the package built on all arches Besides, you might have to version build-dependencies so that they are taken from experimental. Worse, you might have to expand all transitive build-dependencies and version them so that they are taken from experimental (sbuild prefers to fail instead of installing from experimental unless the versioned build-dependency is explicit). This is too impractical with OCaml, for example: it is impossible to make a transition in experimental without an insane amount of work, whereas recompiling all involved packages takes only a few hours (on amd64). > 3/ some maintainers are too confident that nothing is going to break And even if they do tests, they cannot do them on all architectures. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bad3ec1.7020...@glondu.net
Re: Serializing transitions
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 confirmation before actually installing the packages in the archive. Has this ever been considered for the main archive? -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bad4328.9020...@glondu.net
Re: pid file security
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 fooled into restarting a service without checking. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bdfc2ff.5080...@debian.org
Re: why are there /bin and /usr/bin...
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 consequence of the fact that less and less > developers separate /, /usr, /var, etc. partitions on their machines. > In the past I always did it on my workstations, however, stopped doing > it around the time of lenny's release. This is more in favour of dropping the distinction... > Well, just the other day I was helping a user on #debian to repare his > Debian installation, using mostly sed to edit the config files. Nano > was not functional without /usr and it seemed he did not have any > other editor. Booting a fully functional system off a LiveCD (or network / USB key / whatever) is pretty easy these days... Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6d605b.2010...@glondu.net
Re: Does dpkg-buildpackage ignore -sd?
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 affects what is put in the .changes file. What would the source package be if there is no orig tarball? If you don't want a source package to be built, you are probably looking for the "-b" switch. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6ebadc.8080...@debian.org
Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
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 UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c860a6b.8000...@glondu.net
Re: [RFC] Binary packages containing the source
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 could be displayed in such circumstances, though. -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c91cdb7.20...@debian.org
Re: Buildd & binary-indep
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 about building this architecture:all package only in binary-indep? Like in the attached patch... This way, the buildds won't try to build them. Cheers, -- Stéphane wordnet.diff Description: application/pgp-keys
Bug#605487: ITP: aac-tactics -- Coq tactics for reasoning modulo AC
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: OCaml, Coq Description : Coq tactics for reasoning modulo AC This Coq plugin provides tactics for rewriting universally quantified equations, modulo associative (and possibly commutative) operators. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101130152432.10297.63734.report...@aspirine.inria.fr
Re: Why is help so hard to find?
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, you probably version your /etc with some $VCS... it is then easy to recover a configuration file even when its package is purged. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d316306.8020...@debian.org
Re: Why is help so hard to find?
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 file, rather than listing them > all, you then need to repeat this until you've weeded out all the files > one by one until eventually it succeeds. Why don't you just purge all uninstalled packages in one go? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d31620b.1010...@debian.org
Re: Why is help so hard to find?
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 insserv, nor initscripts... I don't remember exactly the circumstances. It was years ago. My conclusion back then was to always purge uninstalled packages, and so I do on most machines I administrate. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d31652a.1040...@debian.org
Re: binNMU for Arch: all packages.
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". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d318350.8030...@debian.org
Re: binNMU for Arch: all packages.
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)
> things become slightly confusing. Again. We've had enough of that with
> ${Source-Version}. And it'll probably break some other stuff as well.
Well... Someone could also make an arch:any package depend on the
${source:Version} of another arch:any package, if he wants to shoot
hisself in the foot. It doesn't prevents binNMUs of arch:any packages.
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d31f558.3040...@debian.org
Bug#610392: ITP: js-of-ocaml -- OCaml bytecode to JavaScript compiler
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 : OCaml bytecode to JavaScript compiler Js_of_ocaml is a compiler of OCaml bytecode to JavaScript. It makes it possible to run OCaml programs in a web browser. Its key features are the following: * the whole language, and most of the standard library are supported; * the compiler is easy to install: it only depends on Findlib and Lwt; * the generated code can be used with any web server and browser; * you can use a standard installation of OCaml to compile your programs. In particular, you do not have to recompile a library to use it with Js_of_ocaml. You just have to link your program with a specific library to interface with the browser APIs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110118093447.17257.36110.report...@aspirine.inria.fr
Bug#615158: ITP: ocaml-cil -- OCaml library for manipulating C programs
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 : OCaml library for manipulating C programs CIL (C Intermediate Language) is a high-level representation along with a set of tools that permit easy analysis and source-to-source transformation of C programs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110226065945.32404.7101.report...@korell.up7.fr
Re: Using Git to maintain many small packages in a team?
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 worked pretty well. We sucessfully converted (almost) all of our svn-buildpackage-managed packages to git (using git-buildpackage) [1]. > Specifically, I'm looking for a way to easy track all of the team's > repositories, update them all, etc. It seems that the Debian Games team > uses mr (according to http://wiki.debian.org/Games/VCS). Are there > alternatives worth considering? We are also using mr, plus a script to generate an mrconfig for the team [2]. [1] http://wiki.debian.org/Teams/OCamlTaskForce/GitMigration [2] http://svn.debian.org/viewsvn/pkg-ocaml-maint/trunk/projects/git-guide/d-o-m-mrconfig.sh?revision=6471&view=markup Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d7368f8.8020...@debian.org
Re: binNMU for Arch: all packages.
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, as
is often the case when you are "simulating" a binNMU with a sourceful
upload in the middle of a transition.
Building "manually" the binNMUed arch:all package at the right time, and
uploading it would achieve a better result, IMHO. And then, all the
arch:any packages (if any) can be binNMUed on the buildds as usual, with
explicit dep-waits, without touching the source package.
One way to handle the substvar issue (which would be more correct to me)
is to add the possibility to specify a version constraint modulo binNMU.
So that Julien's example of [1] would look like:
Package: foo
Architecture: all
Package: bar
Architecture: any
Depends: foo (~= ${source:Version})
(if we choose ~= to denote version equality modulo binNMU). In terms of
implementation, it is conceptually similar to depending on a virtual
package that is provided by the corresponding binary with the same
source version.
[1] http://lists.debian.org/debian-devel/2011/01/msg00480.html
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d78f2f5.1000...@debian.org
Re: Alioth - Convert SVN repo to Git
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 migrate our packages from svn to git, using a (quite hackish) script of mine. See: http://wiki.debian.org/Teams/OCamlTaskForce/GitMigration Among packages owned by pkg-ocaml-maint on alioth, many have been converted this way (see e.g. ocaml, ocsigen, cduce... there are tens of them). The script is pkg-ocaml-maint-specific for now, but should be easily made more generic. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Thoughts on keeping a 3.0 (quilt) package in RCS
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] http://www.vcs-pkg.org/ Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
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: "my /usr is shared by many machines over NFS"? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752051: ITP: ocaml-ipaddr -- library for manipulation of IP (and MAC) address representations
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 Lang: OCaml Description : library for manipulation of IP (and MAC) address representations This is a library for manipulation of IP (and MAC) address representations. . Features: * IPv4 and IPv6 support * IPv4 and IPv6 CIDR prefix support * IPv4 and IPv6 CIDR-scoped address support * Integration with the standard OCaml distribution (Map.OrderedType, Unix, top-level) * IP address scope classification * IPv4-mapped addresses in IPv6 (:::0:0/96) are an embedding of IPv4 * MAC-48 (Ethernet) address support * All types have sexplib serializers/deserializers This library is a dependency of the new version of ocsigenserver. It will be maintained inside the Debian OCaml Maintainer Team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140619055259.6060.66041.report...@korell.up7.fr
Re: devotee (debian vote engine): predictable RNG allows recovery of secret monikers
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 (sysread(UR, $rbytes, 16) < 16); > > my $m = sha1_hex($rbytes); While we're at it, what about giving the possibility to the voter to contribute to the entropy of the moniker? Say, add a field to the ballot and suggest the voter to put e.g. the output of pwgen there? This would be in addition to the above code. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f9a2a94.5050...@debian.org
Re: Build environment bug: 675125
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 sure we don't just > freeze on the current slang but ship the > broken environment. A hint: snapshot.debian.org. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fe16530.2020...@debian.org
Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)
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 simple to implement (I'd volunteer to > do this but wanted to seek for comments before filing a bug report + > patch). There is also the --filter-pristine-tar option to git-import-orig, which can be specified in debian/gbp.conf. We routinely use it in the OCaml team (see e.g. why). Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50464631.1000...@debian.org
Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)
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 pretty simple to implement (I'd volunteer to >>> do this but wanted to seek for comments before filing a bug report + >>> patch). >> >> There is also the --filter-pristine-tar option to git-import-orig, which >> can be specified in debian/gbp.conf. We routinely use it in the OCaml >> team (see e.g. why). > > I'm not sure whether I understand what you want to tell here. Do you > think git-import-orig should filter out / remove files mentioned in > debian/copyright field Files-Excluded? No, I was just mentioning a fourth independently developed solution. If an agreement is reached on Files-Excluded, I guess git-import-orig could also take it into account (probably via a new option, though). Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50483404.6050...@debian.org
Re: Source build-dependencies
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.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519103f4.50...@debian.org
Re: uscan connection error
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.saxonica.co.uk/repos/archive/opensource/tags/ (\d.*)/ > debian debian/orig-tar.sh > uscan warning: In watchfile debian/watch, reading webpage > https://www.saxonica.co.uk/repos/archive/opensource/tags/ failed: > 500 Can't connect to www.saxonica.co.uk:443 > -- Scan finished > > Any clue? Try it in a browser. Wrong SSL certificate. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519481e8.5060...@debian.org
Re: Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]
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 transfer of metadata (name, etc.) with BrowserID, unlike OpenID and WebID. An identity is an e-mail address, period. A benefit compared to OpenID and WebID is that the relying party doesn't need to query the identity provider each time, so this improves privacy. BrowserID also relies on the CA cartel. You need to setup an HTTPS (with a trusted certificate) server that responds to some hard-coded path [1] to implement an identity provider. I see this as a serious limitation, but I guess big identity providers don't care. There is an open issue [1] about looking up information in DNS instead of the current hard-coded path. Maybe this, combined with DNSSEC, could lift the HTTPS constraint. But this is work in progress. [1] https://developer.mozilla.org/en-US/docs/Mozilla/Persona/Implementing_a_Persona_IdP [2] https://github.com/mozilla/browserid/issues/1523 Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51949f6f.3010...@debian.org
Re: Web ID as passwordless authentication for debian web services
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 is. If you're defending against > incompetence and/or commercial greed overriding security practices, DNSSEC > looks a lot more appealing than the CA cartel, since there isn't the same > level of commercial incentive to cut corners and do a crappy job (there's > some, but it's not as bad). But if you're defending against governments, > DNSSEC isn't going to help. I think it's best to assume that both the US > and Chinese governments, at least, can make DNSSEC say what they want it > to if they ever needed to. That might be, but you already have to trust the "DNS cartel" anyway for resolving domain names (which is needed in WebID, BrowserID, ...). You don't have to give trust to new entities when using DNSSEC. -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5195cab5.8090...@debian.org
Re: Web ID as passwordless authentication for debian web services
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. > (Well, you could encrypt it and then distribute a separate key, but that's > getting into pointless complexity.) Whereas in theory your WebID endpoint > could release different metadata depending on who asks. [...] I understood that as the main point of WebID. > [...] But since WebID > doesn't authenticate the entity asking for metadata, I'm not sure that's > really what's going on. The entity asking for metadata can authenticate using the same mechanism... as Jonas pointed out, WebID works also for inter-server authentication. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5195d047.3090...@debian.org
Re: Do opaque struct changes break C library ABIs
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 works, so in practice most > projects don't have any supported platforms where there is a big > technical difference between shared libraries and plugins, and the > line between the two gets blurred. Mac OS X (Darwin) does make the distinction, see [1]. [1] http://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5196247f.30...@debian.org
Re: Do opaque struct changes break C library ABIs
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 information on the topic is available at: http://alain.frisch.fr/flexdll.html -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5196262f.4000...@debian.org
Re: Do opaque struct changes break C library ABIs
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 :-) You simply don't load a plugin without using dlopen(). Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51964760.5020...@debian.org
Re: Developer repositories for Debian
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 active MITM, etc.) depending on the situation. > [...] > The obvious way to authenticate the connection to www.eyrie.org to > retrieve my metadata is to validate the www.eyrie.org certificate against > a CA, which is where the CA cartel is reintroduced into the picture. But if www.eyrie.org is compromised (as you seem to allow), then having a CA-certified certificate won't help, will it? I wouldn't rely on a trust chain involving an online private key in this context... -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51965590.2030...@debian.org
Re: Pepper Flash for Chromium
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 permitted or required by
>> law, or unless you have been specifically told that you may do so
>> by Google, in writing.
>
> Specifically, downloading the chrome .deb from google and doing
> anything other than simply installing it (like extracting the flash
> plugin and copying it elsewhere) would be creating a derivative work
> and is thus forbidden.
>
> Additionally, the EULA says this ('Services' here includes the
> software itself):
>
>> Unless you have been specifically permitted to do so in a separate
>> agreement with Google, you agree that you will not reproduce,
>> duplicate, copy, sell, trade or resell the Services for any
>> purpose.
Has anyone considered asking Google to distribute separately the flash
plugin?
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d94b71.5020...@debian.org
Re: regression: "sh -c" change causes FTBFS
[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 probably >> do the same for the same reason. > > Hold on a second. Dash is not supposed to be a bash emulator. :) > > ksh93 -c "/bin/sleep 100 >dev/null" does skip a fork(). I suspect > bash does not skip a fork in this case for the same reason that > > bash -c 'echo hi; /bin/sleep 100' > > does not skip a fork. POSIX's Shell and Utilities (XCU) 2.12 [1] does say that "[the] environment of the shell process shall not be changed by the utility", and that environment includes open files. My understanding is that dash's new behaviour (and incidentally, ksh93's one) is incorrect. [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_12 Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e8dbcc1.3050...@debian.org
Re: [Pkg-scala-maint] Binary blobs in source packages
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 independent interpreter (resp. OCaml's own bytecode, .NET, Java). A (cross-platform) binary is then bundled with the sources and is used for initial bootstrap. In the OCaml case, a bytecode compiler (ocamlc) is bundled in the upstream tarball, and the build system recompiles it until it reaches a fixpoint. There are also native code backends for selected architectures that can be compiled easily once everything has been compiled in bytecode. -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee7c1ef.8060...@debian.org
Re: On init in Debian
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éphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f7553a0.9060...@debian.org
Re: Automatically satisfying Build-Depends from local control file
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 update and apt-get install $PACKAGE. You can directly use dpkg -i on the generated .deb, then aptitude to fix things up. Or just use the -i option of mk-build-deps. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5170dcf4.5000...@debian.org
Re: multiarch and interpreters/runtimes
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 situation of OCaml wrt multiarch. There are actually two compilers. One of them is the "bytecode" one and uses its own binary format for compiled objects. For pure OCaml code, this bytecode is portable (pretty much like Java). There is no shared library mechanism and all executables are statically linked. There is a FFI mechanism that seems to work like Perl, Python and Java (if there is something fundamentally different between these three, please tell me as I've probably misunderstood something). I expect the same issues here wrt multiarch, but I don't understand them fully yet. Foreign code (from the language point of view, not dpkg's one!) is usually called "bindings" in OCaml community. The bytecode compiler (/usr/bin/ocamlc) and runtime (/usr/bin/ocamlrun, written in C) are equally supported on all Debian architectures. The other compiler is the "native" one (/usr/bin/ocamlopt), which compiles to asm and uses the regular toolchain (as, ld...). There is no shared library mechanism for OCaml code (and the runtime is always statically linked), but the resulting executables can still use shared libraries because of bindings. The native compiler only exists on a handful of architectures. I expect no problems here wrt multiarch (or, let's say no more that with any C program). Note that, though portable, bytecode is usually recompiled on all architectures because of native code (we don't bother to put bytecode and native code in different binary packages). Additionally, there is what is called the "plugin" mechanism with both compilers, which can be thought as an equivalent of dlopen (but not mere FFI). It turns out that most of the files needed for development (static libraries, compiled headers, metadata files) and runtime (bindings for bytecode, libraries in plugin form) are all installed in `ocamlc -where`, which is currently /usr/lib/ocaml, but could be changed easily. This is basically forced by the upstream toolchain (and our policy in Debian). However, there is no real standard for plugins, which can be in `ocamlc -where` or not, depending of the application using them. But AFAIK, there are very few packages that use the plugin mechanism with plugins outside of `ocamlc -where`. So my take would be to move `ocamlc -where` to /usr/lib/$DEB_HOST_MULTIARCH/ocaml (it can be done during the next transition). Most of library packages (runtime AND dev) ship files only there (and in /usr/share). After that, I don't know exactly what needs to be done. Concerning cross-compilation... well, there is no out-of-the-box upstream support for cross-compilation, but I guess it can be hacked (see mingw-ocaml... but Romain Beauxis is more knowledgeable on this). 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. ocaml doesn't build-depend on itself). So no need for cross-compilation there. OCaml has very few build-dependencies (there are Tcl/Tk/libX11, but they are optional) and should always be buildable natively. Concerning embedding the runtime in another application... well, that doesn't seem to happen often. The only case I'm aware of is an Apache module and I don't know exactly how multiarch would interact in that. From what I've seen, when there is a need for OCaml scripting capabilities, the main application is already written in OCaml, and the regular toolchain is used to compile the script into a plugin and load it on the fly. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518586c6.3070...@debian.org
Re: OCaml and running shipped binaries (was Re: multiarch and interpreters/runtimes)
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. ocaml doesn't build-depend on itself). So no need >> for cross-compilation there. OCaml has very few build-dependencies >> (there are Tcl/Tk/libX11, but they are optional) and should always be >> buildable natively. > > Wait, wait, wait... so OCaml ships precompiled binaries and runs them during > the build? It seems so, as it FTBFSes if you remove the binaries from boot/. They are used only for the first phase of bootstrapping. Then, everything is recompiled using the newly compiled binaries. And again. Until there is a fixpoint. Everything that eventually ends up in binary packages has been compiled from source, and using binaries that have been compiled from source. > That's RC, I think. With the way I explained above, I disagree. Also, there is no guarantee that one version of ocaml can compile the next one: a new version of the compiler is free to use the new features it introduces. Upstream only supports compiling one version with itself. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5185e8c5.9020...@debian.org
Re: Merging / and /usr (was: jessie release goals)
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 merge, doing such work could be > much more complicated because user data and system data is mixed in > the file system's hierarchy, it's hard to make sure switching between > different snapshots won't change user data. While if such thing is > done properly, then user won't be bothered about messing up the system > on upgrades or experiments anymore. They can switch among different > working environments easily, without dealing with the odds caused by > multi-boot. What about /etc ? /var ? both contain data that can mess up with a running system... -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518fc4b0.70...@debian.org
Re: jessie release goal: verbose build logs
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 is a useful goal. However, since fixing many different source > packages is a lot of work I recently explored some alternative > approaches. For example, with systemtap we can simply log all execve() > invocations complete with timing information and end up with fully > structured build logs. > > Here's example output from the proof of concept from a few years ago: > > http://lindi.iki.fi/lindi/structured-buildlogs/logs/hello-2.6-1_amd64.build How do you do that exactly? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52837b52.4030...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
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 both kind of special in that they are not >> Linux, it would be good to keep one or the other around even if other >> architectures are culled more aggressively. >> > > 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]. And what about (somehow automatically, like RC-buggy packages) removing packages from testing only on these architectures? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52985e1f.2080...@debian.org
Bug#731598: ITP: camldbm -- binding to the NDBM/GDBM Unix databases
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: C, OCaml Description : binding to the NDBM/GDBM Unix databases This OCaml library is a binding to the NDBM/GDBM Unix databases. It provides persistent storage of key-value pairs of strings. It used to be shipped with OCaml < 4. It now distributed separately and is needed by dose2. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131207132335.13746.58854.report...@korell.up7.fr
Re: Release sprint results - team changes, auto-rm and arch status
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]. >> >> And what about (somehow automatically, like RC-buggy packages) removing >> packages from testing only on these architectures? > > Maybe I am misreading you proposal, but it seems to me that a change > like that would undermine the concept of build regressions being RC for > release architectures. Alternatively, we would end up with > "second-rate" release architectures[1], where build regressions are no > longer RC bugs. However, at that point I am not sure we are willing to > call it a release architecture. My proposal was in response to dropping a release architecture altogether. I had the feeling that this new intermediate status (let's call it "partial", "second-rate", or "technological preview") would not be too much additional work. > [1] Assuming here you don't want packages to be removed from amd64/i386 > when a maintainer uploads a truly broken package to sid and leaves it > there for 3 months. There has been examples of this in the past. If > you look for it, you can probably find an example of it in the archive > right now as well. I don't understand this remark. My proposal doesn't affect release architectures such as amd64/i386. And removals would be only from testing. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52aece6a.9050...@debian.org
Bug#736908: ITP: optcomp -- syntax extension for optional compilation with cpp-like directives
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 for optional compilation with cpp-like directives Optcomp is a syntax extension which handles #if, #else, ... directives in OCaml source files. Compared to cpp: * it does not interpret //, /*, and */ as comment delimiters * it does not complains about missing ' * it is easier to integrate in the build process when using other camlp4 syntax extensions * it does not do macro expansion while cpp does Compared to pa_macro, it does not require code that will be dropped to be valid OCaml code. This can be useful for code that optionnally uses GADTs, but can be compiled with older versions of OCaml. -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140128072456.5249.64877.report...@korell.up7.fr
Bug#742613: ITP: ocaml-ctypes -- library for binding to C libraries using pure OCaml
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 for binding to C libraries using pure OCaml The ocaml-ctypes library makes it possible to call C functions directly from OCaml without writing or generating C code. The core of the library is a set of combinators for describing C types -- scalars, functions, structs, unions, arrays, and pointers to values and functions. Type descriptions can then be used to bind native functions and values. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140325135918.28645.16598.report...@wencory.loria.fr
Re: Ifupdown dysfunctional, is a Provides: interface possible please?
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 like a router/firewall, and they > should not be nfs mounting by their nature and functionality ... Real > corner case stuff. A work station or server can run virtual machines connected via a bridge and mount staff via NFS. This is not a corner case to me. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53366fc9.90...@debian.org
Re: PPA
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 > hold the data, how do we make sure that dependencies are there? > (Basically "how do we extend dak for ppa?") > > 3. How do we extend authentication concepts for apt to ppa? (So that > one could say "please give me this and that repository from ppa", and > one doesn't need to add custom apt-keys.) > > 4. How do we get a good interface to see which patches are where, and > which bugs are found (or fixed) where? > > 5. After 2. is done, setting up autobuilding for ppa. (I'll be happy > to help with this part, but 2. needs to be done first.) 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). I don't see why points 1-4 should be addressed by the project as a whole (and a prerequisite of 5): each PPA maintainer can have its own tool / policy / proposals before everyone agrees on something more unified. On the other hand, custom repositories are always restricted to architectures their maintainer have access to. It would be nice if the autobuilding network would allow submitting jobs not targeted for official suites. Something a PPA maintainer could use to get the binary packages for architectures he doesn't have access to. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dbd756d.8090...@debian.org
Re: PPA
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 easy for one piece of software. I maintained more than one dak > instance already. > > However, to get that done right for multiple software is not so easy. What do you mean by "right"? Have you ever used Lauchpad's PPAs? Does it qualify as "right"? PPAs are not perfect... but they are practical and useful enough for developers and users. > Well yes, but how many autobuilding suites should we add? 50? 100? > 200? How do we do key management so that we know that the autobuilder > build the packages that they should? Why would we need more suites? I was thinking of a request that would include a base suite (e.g. squeeze, wheezy, or sid), files to drop in /etc/apt/sources.list.d (and /etc/apt/preferences.d), and the key used to sign unofficial repositories. Of course, the request itself would be signed (like *.changes or *.commands files on ftp-master). Then a buildd accepting a job would add the key with apt-key, drop the files in /etc/apt, upgrade and launch the build as usual... the whole thing done in a throw-away chroot, obviously (I use cowbuilder myself for that, but I heard that sbuild had support for LVM snapshots). -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dbd8920.6010...@debian.org
Bug#633953: ITP: tyxml -- typed XML in OCaml
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 Description : typed XML in OCaml TyXML allows one to build XML trees whose validity is ensured by the typechecker. It's based on a traduction of XML types into polymorphic variants, originally written by Thorsten Ohl. Currently, the transcription has been done for XHTML 1.0 and 1.1, HTML5 and SVG (partial). . TyXML also provides a generic printer and some low-level (and untyped) iterators over XML trees. The printer has options for printing XHTML in more browser-friendly way when served as "text/html" (instead of "text/xml"). HTML5 is always printed with those options. . All modules provided by TyXML are also provided in functorial interface, where every module is parameterised by the underlying XML representation. . A camlp4 extension, named Pa_tyxml, allows one to write HTML pages or HTML fragments with the usual syntax. Part of this library is already part of Ocsigen 1.3. It has been split out and extended, and is a new dependency of Ocsigen 2. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715113748.26198.15494.report...@korell.up7.fr
Bug#635170: ITP: ocaml-config-file -- OCaml library for managing configuration files
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 : OCaml library for managing configuration files Config_file is an OCaml library used to manage the configuration file(s) of an application. You simply define your options and it performs the loading and saving of the options. Each option is defined from an option class (for example an "int" option) or from a combination of classes (for example to create "list of int" options). This library used to be part of cameleon, but has been split out, and is a new dependency of the new upstream version 1.9.21. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110723112614.19753.83508.report...@korell.up7.fr
Bug#635586: ITP: lablgtk-extras -- collection of modules for OCaml/LablGtk2 applications
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 Description : collection of modules for OCaml/LablGtk2 applications Lablgtk-extras is a collection of libraries and modules useful when developing OCaml/LablGtk2 applications. Most of the libraries come from Cameleon2: * Configwin: a library to easily create input dialog boxes, * Okey: a module to add handlers for key press events, * Gtksv_utils: a module to share configuration of colors, fonts, ..., between applications using LablGtkSourceView, with functions and boxes to make the user edit configuration of languages and source views. This library used to be part of cameleon, but has been split out, and is a new dependency of the new upstream version 1.9.21. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110727092036.17141.10628.report...@aspirine.inria.fr
Bug#777609: ITP: nproc -- process pool implementation for OCaml
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 : process pool implementation for OCaml Nproc is a process pool implementation for OCaml. A process pool is a fixed set of processes that perform arbitrary computations for a master process, in parallel and without blocking the master. Master and workers communicate by message-passing. Nproc relies on fork, pipes, Marshal and Lwt. This package will be maintained in the Debian OCaml Team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150210165540.28893.83195.report...@wencory.loria.fr
Re: Bug#777609: ITP: nproc -- process pool implementation for OCaml
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54db23b4.6010...@debian.org
Bug#778521: ITP: camlp4 -- Pre Processor Pretty Printer for OCaml
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 Pretty Printer for OCaml Camlp4 is a software system for writing extensible parsers for programming languages. It provides a set of OCaml libraries that are used to define grammars as well as loadable syntax extensions of such grammars. Camlp4 stands for Caml Preprocessor and Pretty-Printer and one of its most important applications is the definition of domain-specific extensions of the syntax of OCaml. Camlp4 used to be part of OCaml, but has been distributed separately since OCaml 4.02.0. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150216082536.5133.47711.report...@wencory.loria.fr
Bug#779039: ITP: labltk -- OCaml bindings to Tcl/Tk
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 bindings to Tcl/Tk mlTk is a library for interfacing OCaml with the scripting language Tcl/Tk. This library used to be distributed with OCaml, but is now distributed separately. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150223155159.17922.34686.report...@wencory.loria.fr
Bug#779574: ITP: ppx-tools -- tools for authors of OCaml syntactic tools
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 : tools for authors of OCaml syntactic tools This package includes tools for authors of syntactic tools (such as ppx rewriters). This package is a new dependency to the lwt package, and will be maintained in the Debian OCaml Team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150302151945.24878.52322.report...@wencory.loria.fr
Bug#791658: ITP: uutf -- OCaml UTF streaming codec
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 codec Uutf is an non-blocking streaming Unicode codec for OCaml to decode and encode the UTF-8, UTF-16, UTF-16LE and UTF-16BE encoding schemes. It can efficiently work character by character without blocking on IO. Decoders perform character position tracking and support newline normalization. . Functions are also provided to fold over the characters of UTF encoded OCaml string values and to directly encode characters in OCaml Buffer.t values. . Uutf is made of a single, independent, module. Uutf is a new dependency of Tyxml. It will be maintained in the Debian OCaml team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150707095413.17097.58680.report...@wencory.loria.fr
Re: Ad-hoc survey of existing Debian git integration tools
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 git-format-patch. Most of packages maintained
by Debian OCaml Maintainers use it.
Cheers,
--
Stéphane
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55adfc42.4020...@debian.org
Conflict over /usr/bin/dune
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 install programs with different > functionality but with the same filenames. The solution proposed by the policy is to rename one or both of the packages, after a discussion here: > [...] try to find a consensus about which program will have to be > renamed. If a consensus cannot be reached, both programs must be > renamed. The "dune" package (of which I am the maintainer) is a popular build system for OCaml projects. It is pretty recent, has strong upstream support, and more and more projects are switching to it, which is a reason to have it in Debian. It was previously named jbuilder, but has been renamed due to a conflict with another software. Upstream is reluctant to rename it again. The "whitedune" package is a graphical VRML97/X3D viewer, editor, 3D modeller and animation tool. It has existed in Debian since 2007 and its last upload to Debian (an NMU) dates back to March 2016. The version in Debian is 0.30.10 while the last upstream version [1] seems to be 0.99pl1234. The source tarball seems to date back to December 2018, so the upstream project seems well alive. In the "whitedune" package, "/usr/bin/dune" is a symbolic link to "whitedune". [1] http://wdune.ourproject.org/ Due to its nature, the build system (a command line tool) is more likely (IMHO) to be invoked as "dune" by third-parties than the desktop application. Moreover, the existence of the symlink suggests that the preferred way to call the application is through "whitedune" (and a menu entry exists). Therefore, I propose that the "whitedune" package drops the "/usr/bin/dune" symlink altogether. Cheers, -- Stéphane
Bug#933830: ITP: ocaml-num -- legacy Num library for arbitrary-precision integer and rational arithmetic
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 : legacy Num library for arbitrary-precision integer and rational arithmetic This library implements arbitrary-precision arithmetic on big integers and on rationals. This is a legacy library. It used to be part of the core OCaml distribution (in otherlibs/num) but is now distributed separately. New applications that need arbitrary-precision arithmetic should use the Zarith library (https://github.com/ocaml/Zarith) instead of the Num library, and older applications that already use Num are encouraged to switch to Zarith. Zarith delivers much better performance than Num and has a nicer API. Several packages depends on this in Debian, including: scilab, z3, coccinelle, ocaml-batteries. The package will be maintained by the ocaml-team.
Bug#934149: ITP: ocaml-sexplib0 -- Library containing the definition of S-expressions and some base converters
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 : Library containing the definition of S-expressions and some base converters Part of Jane Street's Core library The Core suite of libraries is an industrial strength alternative to OCaml's standard library that was developed by Jane Street, the largest industrial user of OCaml. This package is needed by postgresql-ocaml >= 4.1.0. It will be maintained inside ocaml-team.
Bug#934150: ITP: janest-base -- Full standard library replacement for OCaml
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 standard library replacement for OCaml Base is a complete and portable alternative to the OCaml standard library. It provides all standard functionalities one would expect from a language standard library. It uses consistent conventions across all of its module. Base aims to be usable in any context. As a result system dependent features such as I/O are not offered by Base. They are instead provided by companion libraries such as ocaml-stdio. This package is needed by postgresql-ocaml >= 4.1.0. It will be maintained inside ocaml-team.
Bug#934152: ITP: ocaml-stdio -- Standard IO library for OCaml
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 library for OCaml Stdio implements simple input/output functionalities for OCaml. It re-exports the input/output functions of the OCaml standard libraries using a more consistent API. This package is needed by postgresql-ocaml >= 4.1.0. It will be maintained inside ocaml-team.
Bug#934154: ITP: ocaml-integers -- Various signed and unsigned integer types for OCaml
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 : Various signed and unsigned integer types for OCaml The ocaml-integers library provides a number of 8-, 16-, 32- and 64-bit signed and unsigned integer types, together with aliases such as long and size_t whose sizes depend on the host platform. This package is needed by ocaml-ctypes >= 0.12. It will be maintained inside ocaml-team.
Bug#934890: ITP: ppxlib -- meta-programming for OCaml
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 for OCaml The ppxlib project provides the basis for the ppx system, which is currently the officially supported method for meta-programming in OCaml. It offers a principled way to generate code at compile time in OCaml projects. It features: * OCaml AST / parser / pretty-printer snapshot, to create a full frontend independent of the version of OCaml; * library for ppx rewriters in general, and type-driven code generators in particular; * feature-full driver for OCaml AST transformers; * quotation mechanism allowing to write values representing the OCaml AST in the OCaml syntax; * generator of open recursion classes from type definitions. This is a new dependency of many OCaml packages, including obus. It will be maintained inside ocaml-team.
Bug#934896: ITP: janest-ocaml-compiler-libs -- OCaml compiler libraries repackaged
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: OCaml Description : OCaml compiler libraries repackaged This package simply repackages the OCaml compiler libraries so they don’t expose everything at toplevel. For instance Ast_helper is now Ocaml_common.Ast_helper. The special library ocaml_shadow adds a deprecation warning on all modules from the compiler libraries, to force the user to use the prefixed names. This is a dependency of ppxlib. It will be maintained inside ocaml-team.
Bug#935875: ITP: ocaml-mmap -- file mapping functionality in OCaml
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 Description : file mapping functionality in OCaml This project provides a Mmap.map_file functions for mapping files in memory. This function is the same as the Unix.map_file funciton added in OCaml >= 4.06. This package is a new dependency of lwt. It will be maintained in ocaml-team.
Bug#939011: ITP: ocaml-stdcompat -- compatibility module for OCaml standard library
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 : compatibility module for OCaml standard library Stdcompat is a compatibility layer allowing programs to use some recent additions to the OCaml standard library while preserving the ability to be compiled on former versions of OCaml. . The module Stdcompat provides some definitions for values and types introduced in recent versions of the standard library. These definitions are just aliases to the matching definition of the standard library if the latter is recent enough. Otherwise, the module Stdcompat provides an alternative implementation. This package is a dependency of pyml, which is a replacement for pycaml and needed by coccinelle. It will be maintained in ocaml-team.
Bug#939555: ITP: ppxfind -- tool combining ocamlfind and ppx
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 Programming Lang: OCaml Description : tool combining ocamlfind and ppx Ppxfind is a small command line tool that allow to apply ppx rewriters installed on the system on a file. It supports both new style ppx rewriters (driverised) and old styles ones. This package is a new dependency of ppx-deriving. It will be maintained in ocaml-team.
Bug#939557: ITP: ocaml-charinfo-width -- determine column width for a character
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 : determine column width for a character This module is implemented purely in OCaml and the width function follows the prototype of POSIX's wcwidth. This package is a new dependency of zed. It will be maintained in ocaml-team.
Bug#940039: ITP: ocplib-endian -- optimised functions to read and write int16/32/64
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 functions to read and write int16/32/64 Optimised functions to read and write int16/32/64 from strings, bytes and bigarrays, based on primitives added in version 4.01. . The library implements three modules: * EndianString works directly on strings, and provides submodules BigEndian and LittleEndian, with their unsafe counter-parts; * EndianBytes works directly on bytes, and provides submodules BigEndian and LittleEndian, with their unsafe counter-parts; * EndianBigstring works on bigstrings (Bigarrays of chars), and provides submodules BigEndian and LittleEndian, with their unsafe counter-parts. This package is a new dependency of lwt >= 4. It will be maintained in ocaml-team.
Bug#940318: ITP: lwt-log -- Lwt-friendly logging library
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-friendly logging library Lwt_log is a Lwt-friendly logging library. The library is split into two ocamlfind packages. The "basic" lwt_log includes Unix log destination support, such as files and syslog, and Lwt_daemon. lwt_log.core is the pure-OCaml part of lwt_log, suitable for targeting JavaScript in the browser, or elsewhere where Unix is not available. This is a new dependency of lambda-term and obus. It will be maintained in ocaml-team.
Bug#1041684: ITP: not-ocamlfind -- front-end to ocamlfind to add a few new commands
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 * License : MIT Programming Lang: OCaml Description : front-end to ocamlfind to add a few new commands The command not-ocamlfind is a pass-thru to ocamlfind, but adds three new commands: preprocess, reinstall-if-diff and package-graph. This package is a new dependency of camlp5. It will be maintained in the OCaml team.
Bug#1042958: ITP: camlp5-buildscripts -- Camlp5 build scripts
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-buildscripts * License : MIT Programming Lang: OCaml Description : Camlp5 build scripts These are build-scripts that are helpful in building Camlp5 and packages based on Camlp5. As such, they need to not depend on Camlp5. The command are not installed in a bin-directory, but in the package-directory, hence invoked via the "ocamlfind package/exe" method. This is a new dependency of camlp5 and will be maintained in the OCaml team.
