Re: GCC 4.4 run-time license and non-GPLv3 compilers
On Fri, Apr 10, 2009 at 06:49:04PM +0200, Florian Weimer wrote: > > * Stéphane Glondu: > > The FSF obviously wants to outlaw proprietary compilers that use > > intermediate representations of GCC. Using GCC as a C-to-asm compiler is > > fine, even in a proprietary project. The FAQ states explicitly that a > > program generating a C file, for example (which might be a compiler in > > fact), doesn't take part in the "compilation process". So one could even > > make a proprietary compiler using C as an intermediate langage, and GCC > > for the final stage, I guess. > > Well, this is an argument why the FSF might not like the effect of the > run-time library exception on Objective Caml. I don't think it's a Just for information, the run-time library exception on Objective Caml was suggested by Richard Stallman himself, back when the Objective Caml licence was non-free. He did give some example of another case, in GCC itself if i remember well, where a similar exception was used. His mail is probably in the archive, but if it is not, i would be glad to dig into my mail archive and resend the email, and maybe you could use it in your communication attempt ? Maybe we could address Richard Stallman himself on this topic too ? BTW, Florian, please forward this email to debian-legal and debian-gcc, as i am being censored and this mail won't reach those lists, even though it is on-topic. /me is still disgusted by seeing debian squible about minor non-free-ness like these, and having no problem applying stalinist censorship on its own mailing list, freedom is not only for software, you know. But then, i have seen that DDs are just a bunch of hypocrits, in seeing how the non-free firmware case was handled. Sadly, Sven Luther -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Dropping arm/ia64 opt compilers [was: felix regression on arm?]
On Tue, Oct 02, 2007 at 08:44:31PM +, Sylvain Le Gall wrote: > On 02-10-2007, Mike Furr wrote: > > Stefano Zacchiroli wrote: > >> John, > >> do you have any explanation for the felix test failure on arm? > > > > I believe the problems on arm and ia64 are both OCaml compiler bugs. > > These are been reported upstream for a couple of programs that are in > > debian [1,2,3] and have all been essentially marked "wontfix" by the > > OCaml guys since they don't have ready access to those architectures. > > > > So, I think we should probably consider dropping the native compilers on > > those architectures until they are supported better (either by upstream > > or some adventurous DD with knowledge of those archs). > > > > Cheers, > > -Mike > > > > [1] - http://caml.inria.fr/mantis/view.php?id=3077 > > [2] - http://caml.inria.fr/mantis/view.php?id=3908 > > [3] - http://caml.inria.fr/mantis/view.php?id=3952 This last issue seem to be fixed : xleroy (2008-02-20) Thanks for the ARM patch. It is applied in the 3.10 bugfix branch and will be part of the 3.10.2 release. I wonder if there was another reason for the arm native code compiler not being built (am playing with arm hardware currently, thus the curiosity, altough i only have cross compilers set up right now, which don't play well with ocaml). Both ia64 and arm as noted as tier-2 supported in the 3.11 README file. Friendly, Sven Luther -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DM application for Mehdi Dogguy
On Thu, Oct 02, 2008 at 03:48:02PM +0200, Mehdi Dogguy wrote: > > > > Romain Beauxis wrote: > >Le Thursday 02 October 2008 14:02:26 Mehdi Dogguy, vous avez écrit : > >>>Cool and good luck to you. > >>Thanks :) > >>I'm waiting for a DD reply but Sam seems busy these days > > > >Cool and good luck to you :-) > > > >What do you expect more from a DD (sorry I know nothing about DM things..) > > > > At least one DD should approve my application by a signed reply to my > message > on debian-newmaint. In a perfect world, it would be my sponsor and > someone else. Well, i would gladly recomend you, but well, given the current clima it may be counter-productive, so i leave this to others if i am not needed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DM application for Mehdi Dogguy
On Wed, Oct 01, 2008 at 08:46:49PM +0200, Mehdi Dogguy wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > [Forgot to CC it to d-o-m] > > Hello all, > > I would like to apply for Debian Maintainership. Samuel Mimram is my > sponsor and advocate. Cool and good luck to you. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocamlp3l_2.03-1_amd64.changes REJECTED
On Wed, Sep 10, 2008 at 09:09:42AM +0200, Joerg Jaspert wrote: > > >> rejected, seems we miss the source for the included papers/hlpp05/*. > > Come on Joerg, are you really saying that you need the sources of the > > scientific papers included in the tarball ? This is not plain > > documentation but scientific papers, and as thus, it seem normal to not > > provide the sources. > > Yes, I say that we need the sources of everything we upload. So, this applies also to the bunch of remaining linux kernel firmware which will be removed before the lenny release, as well as the non-free GPL copyright document ? Or numerous other problematic cases in the archive ? Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocamlp3l_2.03-1_amd64.changes REJECTED
On Tue, Sep 09, 2008 at 11:33:39PM +0200, Stefano Zacchiroli wrote: > On Tue, Sep 09, 2008 at 10:50:21PM +0200, Sven Luther wrote: > > Come on Joerg, are you really saying that you need the sources of the > > scientific papers included in the tarball ? This is not plain > > documentation but scientific papers, and as thus, it seem normal to not > > provide the sources. > > No, it is not normal. Oh, and you pobably provide the latex sources of your scientific articles ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocamlp3l_2.03-1_amd64.changes REJECTED
On Tue, Sep 09, 2008 at 06:59:48PM +, Joerg Jaspert wrote: > > Hi Maintainer, > > rejected, seems we miss the source for the included papers/hlpp05/*. Come on Joerg, are you really saying that you need the sources of the scientific papers included in the tarball ? This is not plain documentation but scientific papers, and as thus, it seem normal to not provide the sources. I remember you that we also don't have modification rights on the GPL license, so i guess that if you really want to go fanatic on this one, you are facing worst problems. > Also, the license headers of a lot of the examples doesnt make me happy. > "All rights reserved. This file is distributed only by permission.". > That can't, in this way, ever go into main. I had a look on the upstream package, and only the DomainDecomposition example seems to be in this case. And the copyright of this is 2003-2007, so it is probably a license going back to 2003 and never changed since then. Knowing the author, i suppose we could just ask him to relicence or something. Still 'a lot of' seemsa bit different from a single example :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#256900: Ocaml compiled programs cannot be stripped
On Wed, Aug 20, 2008 at 05:19:17PM +0200, Xavier Leroy wrote: > > Hello Sven, > > >>> 1- "ocamlc -custom" is deprecated and packages that use it should be > >>> fixed. > >>> > >> If this option is deprecated, i think we should handle it so for all > >> debian package. See at the end of the mail for a proposed way of doing > >> thing. > > > > One question though which comes to mind while reading this thread. When > > was the -custom version deprecated, and what does this imply for the > > version of ocaml in debian which will ship with lenny. > > OK, maybe "deprecated" isn't the right word. :) > The -custom option is not deprecated in the sense of "it will be > removed at some point in the future". We Caml people take backward > compatibility very very seriously. This option is here to stay, > but not to be improved, because: Well, let's rephrase this, since when is the shared stub way "recomended" over the -custom version. This was the first time that i really heard about this, altough i have been trying to do away with the -custom flag in projects since some time. Often folk only use -custom to do away with the dependencies, and kind of create a "static" version of the binary, which is easier to install standalone, which is not the debian use-case. > The -custom option is deprecated in the sense that, since the > introduction of dynamic loading of stub libraries in the bytecode > interpreter circa 2001, there exists a much better alternative: > put the native stubs into shared libraries and produce "pure" bytecode > executables that dynamically load these libraries. This is better > than -custom for several reasons: > > - smaller executables; > - bytecode executables can be shared across different platforms; > - it is possible to use such mixed Caml/native libraries from the toplevel. Indeed :) > So, I think everyone should be gently encouraged to use shared libs > instead of -custom. Especially since, as I mentioned earlier, some > Caml projects that started before 2001 still force -custom when > linking with standard libraries like unix.cma or str.cma, while this > is now entirely unnecessary. > > Hope this addresses your concerns. So, are you officially "gently encouraging" ? Is the community really aware of your position ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#256900: Ocaml compiled programs cannot be stripped
On Wed, Aug 20, 2008 at 01:51:20PM +0200, Sylvain Le Gall wrote: > > Hello, > > On Mon, Aug 18, 2008 at 05:46:50PM +0200, Xavier Leroy wrote: > > > First, a few reminders: > > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900 > > > http://caml.inria.fr/pub/ml-archives/caml-list/2004/07/181268104b59b10ed1624cb92ed996c4.fr.html > > > > > > Is there any news on this issue? It seems it is still on topic in OCaml > > > 3.10.2... > > > > The plan of action that Sylvain Le Gall discussed with me a while ago > > was to track down the OCaml packages that use "ocamlc -custom" and fix > > them to use shared libraries instead. Many mature Caml sources still > > use the -custom option although it is no longer necessary. I can > > provide assistance tracking down the mixed bytecode/native executables > > that are a problem. > > > > To summarize, my take on this issue is: > > > > 1- "ocamlc -custom" is deprecated and packages that use it should be fixed. > > > > If this option is deprecated, i think we should handle it so for all > debian package. See at the end of the mail for a proposed way of doing > thing. One question though which comes to mind while reading this thread. When was the -custom version deprecated, and what does this imply for the version of ocaml in debian which will ship with lenny. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ia64/unstable: FTBFS: needs ocamlopt
On Fri, May 30, 2008 at 04:38:06PM +0200, Stefano Zacchiroli wrote: > On Fri, May 30, 2008 at 03:43:56PM +0200, Sven Luther wrote: > > The problem is either : > > Sven, are you reading posts before posting? I did read the posts, but i admit i did not check the bug reports for the other mail where i claimed this to be RC. > I've already stated in this thread that "ia64" is *NOT* in the Arch > field of neither spamoracle, nor ara. And it has been explained by > others why the buildds are trying to build the packages. Yes, but the question of the parent post, seemed to show that this was not clear enough, so i tried to be complete and didactic as possible. I also was not entirely sure, so i showed both possibilities, clearly saying that i thought it was probably the second case. But you are right, i am quite busy right now, and well since the sad events we all know, my time and involvement in debian is almost nil, so i try to be helpful when i can, but may miss some of the more verbose and not clearly said points in various mails, or may have missed recent developments. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ia64/unstable: FTBFS: needs ocamlopt
On Fri, May 30, 2008 at 03:28:01PM +0200, Florian Weimer wrote: > * George Danchev: > > > What we are supposed to do with FTBFS like #483280, #483307, and similar > > where > > ocamlopt binary is just not available on these particular architectures, in > > that case IA-64 ? Should we just set the severity to important as Luk Claes > > did for #483280 and wait for upstream to provide support for IA-64 or > > should > > we remove ia64 from Architecture: list ? > > Why can't you switch to the bytecode compiler instead? Actually, the packages are spamoracle and i think ara for the second, which are pure ocaml packages, and as thus will get in a spamoracle-byte version, which is arch: all, and will be built once for all arches and a spamoracle version, which is arch: , and contains the ocamlopt version. The problem is either : - we forgot to remove the arch: ia64 and co after droppign them from the native arches, altough i don't think this happened, as we had automated the generation of the native arches entry in debian/control some years ago. - the autobuilder ignore the arch: field, and try to build the package just the same, and thus fail, which is what is happening here in most probability. If so, the buildds are self to blame for trying to build a package they where told not to build. I remember some time ago, the autobuilders where indeed tryign to build packages even though they where not marked as being built for that arch, because some maintainers where restricting the arches abusively. This in my opinion is an error of the buildd maintainers, and instead of not trusting the maintainers, and effort to educate them should have been made. Well, all this was years ago, not sure how things are now, i have been quite absent from debian's day to day work since some time. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ia64/unstable: FTBFS: needs ocamlopt
On Wed, May 28, 2008 at 10:28:04PM +0300, George Danchev wrote: > Hello calmers ;-), > > What we are supposed to do with FTBFS like #483280, #483307, and similar > where > ocamlopt binary is just not available on these particular architectures, in > that case IA-64 ? Should we just set the severity to important as Luk Claes > did for #483280 and wait for upstream to provide support for IA-64 or should > we remove ia64 from Architecture: list ? > > By the way, I'd like to thank Stefano and Sylvain for improving the (my;-) > ara > package and *documenting* that in README.Debian-source! I'm already a DD, so > I can upload myself, but I'd love to co-maint/co-develop it together. Just jumping in, but these packages are RC-buggy, and the policy says what to do with them, no ? I think the correct severity is grave, fails to follow policy. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted ocaml 3.10.2-3 (source all amd64)
On Tue, May 20, 2008 at 09:10:24AM +0200, Stefano Zacchiroli wrote: > On Mon, May 19, 2008 at 10:17:08PM +, Ralf Treinen wrote: > > ocaml (3.10.2-3) unstable; urgency=low > > . > >[ Stefano Zacchiroli ] > >* debian/rules: force using gcc-4.2 on arm (fix FTBFS on arm) > > . > >[ Ralf Treinen ] > >* Added myself to uploaders. > > Some good and some bad news about the upload. Good: the segfault on arm > went away and all other archs (beside s390 on which the build is > ongoing) built ocaml successfully. Bad: on arm the build failed again, > this time for a docbook2html (actually jade) segfault: > http://buildd.debian.org/fetch.cgi?pkg=ocaml;ver=3.10.2-3;arch=arm;stamp=1211241095 > > IIRC this happened also during the last transition, and anyhow is not a > bug in ocaml since everywhere else docbook2html worked properly. What I > did not remember is how it was solved, was it just "luck" with the next > arm build attempt, or was the build scheduled on some other arm machine? BTW, isn't the docbook2html stuff something we could split into an arch-indep package, so as to not have problems of this kind in the future ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.10.2 transition scheduled for next week
On Wed, May 14, 2008 at 05:03:14PM +0200, Romain Beauxis wrote: > Le Wednesday 14 May 2008 16:38:30 Sven Luther, vous avez écrit : > > > This could be a bug at buildd's side don't you think ? > > > > just depend on ocaml-compiler-libs- and be done with it ? > > Well, yes, surely, but again, it should be fixed in each packages. > In any way, I can version each build-dep when preparing a backport, which I > do > now... > > But, although you may think of these changes when preparing a backport, it's > not obvious you have to do it when uploading to experimental, so you might > forget about it. The idea is that you just rebuild the debian/control and upload, and it should build all alone without further intervention. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.10.2 transition scheduled for next week
On Wed, May 14, 2008 at 04:28:07PM +0200, Romain Beauxis wrote:
> Le Wednesday 14 May 2008 16:20:22 Sven Luther, vous avez écrit :
> > > Hence, ocaml-compiler-libs is pulled from etch, which itself pulls ocaml
> > > 3.09.2-9 which turns out to be incompatible with the ocaml-nox from
> > > backports.org, installed as a forced versioned dependency.
> >
> > Romain, why is ocaml-ompiler-libs pulled from etch, and not from
> > backport.org ? This seem to be the fundamental problem you are
> > experiencing, and the fact that this breaks, is probably a feature and
> > not a bug.
>
> Yea :)
> As I said, backports.org and experimental buildds try to pull the less
> possible packages from backports.org/experimental.
>
> The real bug for me is the impossibility to reproduce it beforehand. Hence,
> it's defined as it's implemented...
>
> > > The same issue happen for experimental.
> > >
> > > My opinion on this is that build dependencies for packages using both
> > > ocaml-nox and other incompatible packages should be versioned for all of
> > > them, but perhaps it is also possible to add lines in the form of:
> > > Conflicts: xxx (>>${binary:Version}), xxx (<<${binary:Version})
> > > in the control file from ocaml source package, where necessary..
> >
> > Did we not use the ocaml- and co virtual packages for this ?
>
> Yes, so ocaml-ompiler-libs pulled from etch requires ocaml-nox-OLD_API, which
> later conflicts and then break the whole resolution process.
>
> Of course, a more correct resolution would recover from the failure and try
> another ocaml-ompiler-libs, like from backports.org
>
> This could be a bug at buildd's side don't you think ?
just depend on ocaml-compiler-libs- and be done with it ?
I seriously think the issue is the same one we used to have 2-3 years
ago about backports, maybe you should look at the old archive of the
mailign list about it.
As i remember the thing, packages should be able to build with any
ocaml-API, but you needed to generate the control from a control.in,
which looked at the ocamlc being used and grabbed the API from that or
something, i think ocaml-nox installed the API in some file which was
read. This API number can then be used to place in control all the APIed
version of the dependencies, and the buildd have then no problem in
grabbing those.
I think that there was a bug in 2001/2002 in the buildd about virtual
packages, of which James Troup told me : it is not supported by buildds,
so don't do it, but i spoke with James and Anthony at debconf oslo about
it, and i think it has been solved since then, my memory may be sketchy
though.
That said, when we did the above, CDBS using packages had some built
debian/control.in calls which kind of break this, not sure what happened
since them, i myself think SDBS is an abomination, but then to everyone
his own :)
Friendly,
Sven Luther
>
>
>
> Romain
> --
> son, daddy left you were from you were four
> I've got to struggle 'cos I am poor
> she said, food is a very hard thing to find
> sometime I feel like I'm going out of my mind
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.10.2 transition scheduled for next week
On Tue, May 13, 2008 at 12:48:38AM +0200, Romain Beauxis wrote:
> Le Monday 12 May 2008 16:01:43 Stefano Zacchiroli, vous avez écrit :
> > - ocaml (obviously)
> > * here it should be a good idea to change the doc-base section for the
> > documentation to the correct one: Ralf: can you do that (as you
> > remember which one is correct :))?
> > * Sylvain: can you please commit the policy changes regarding camlp4
> > naming?
>
> * Dependencies between packages:
> I've recently changed some dependencies [1], after talking with the list [2].
>
> Still there are some build failures [3]. In this example, the build
> dependencies are resolved while trying to minimize the packages pulled from
> backports.org.
>
> Hence, ocaml-compiler-libs is pulled from etch, which itself pulls ocaml
> 3.09.2-9 which turns out to be incompatible with the ocaml-nox from
> backports.org, installed as a forced versioned dependency.
Romain, why is ocaml-ompiler-libs pulled from etch, and not from
backport.org ? This seem to be the fundamental problem you are
experiencing, and the fact that this breaks, is probably a feature and
not a bug.
> The same issue happen for experimental.
>
> My opinion on this is that build dependencies for packages using both
> ocaml-nox and other incompatible packages should be versioned for all of
> them, but perhaps it is also possible to add lines in the form of:
> Conflicts: xxx (>>${binary:Version}), xxx (<<${binary:Version})
> in the control file from ocaml source package, where necessary..
Did we not use the ocaml- and co virtual packages for this ?
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.10.2 transition scheduled for next week
On Tue, May 13, 2008 at 02:39:54PM +0200, Romain Beauxis wrote: > Le Tuesday 13 May 2008 11:13:54 Sylvain Le Gall, vous avez écrit : > > Maybe others have better idea than I... But i think versionned build > > deps, is the best option... > > Yes, that's my point too. > > But this is relevant for both backports.org and experimental. > > I have updated the wiki page about backports.org, perhaps we could enforce > this for experimental uploads too ? I only follow this by far, but had we not some setup which grabbed the ocaml- meta package dependency automatically and generated the debian/control with it, depending on the installed ocaml package, or at least the one used to build ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml
On Mon, May 05, 2008 at 12:41:36PM +0200, Stefano Zacchiroli wrote: > On Mon, May 05, 2008 at 11:32:46AM +0200, Sven Luther wrote: > > I don't even know what this bin-prot thingy does, do you have a link or > > something to an explanation ? > > It provides support for type-safe serialization of OCaml types. Like the marshall module of the standard library ? > Serialization/deserialization functions are generated on the fly using > camlp4 out of the type declaration, using the "with bin_io" modifier. > E.g.: > > type foo = Foo with bin_io Ok. I guess that to give a sound advice, i need to look at the code and what is exactly done. > The quickest pointer to understand what is this about is the README > contained in the distribution tarball. The latter is available at > http://ocaml.janestcapital.com/?q=node/13 . The README.txt says : Currently only little endian (2) computer architectures are supported. Some architectures may potentially also suffer from data alignment issues with this library. Only Intel architectures are currently well-tested. Both 32bit and 64bit architectures are fully supported. Which basically explains the problematic we are faced. On powerpc, there are asm instructions which allow to do the conversion, either separatedly, or while loading/storing data. I suppose that this kind of instructions are available for other big endian arches too, so the less costly way to do this, is to use those instructions on a per arch basis. But this asks the question of how well integrated into ocaml this module is, and how we can do direct asm calls with the less overhead in ocaml, ideally this should be added at the native code generation level, but i don't think ocaml has this kind of functionality right now. I will try to find some time to find out more, or alternatively, we can discuss in live at some time in paris ? I ill be around paris half of may and most of june. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml
On Mon, May 05, 2008 at 11:07:42AM +0200, Stefano Zacchiroli wrote: > On Mon, May 05, 2008 at 10:10:16AM +0200, Sven Luther wrote: > > BTW, i followed this only by far, but have you communicated with > > upstream about this situation, and what is their opinion on this ? > > The best path ATM seems what has been outlined by Markus Mottl on the > caml list: encoding the fact that the stuff is little endian and to the > conversion back and forth on big endian machine at serialization and > deserialization time. I've asked Markus (still on the mailing list, see > the "core has landed" thread) if they plan to release this in the next > release; I'm waiting for an answer. > > > If there is a need to patch cor/bin-proto, maybe the best way is to > > provide the patch upstream and discuss it with them in order to not need > > a patch in the future ? > > Sure it is, but it need someone who does the patch. I've worked enough > on the whole stuff, and I'm fine for a while :) Maybe you are interested > in drafting a patch for bin-prot? IIRC you have experience with big > endian architectures ... Let us know if you are interested. I'm sure > upstream will welcome patches in the direction of big endian support. Interest, yes, but sadly not enough time right now. I don't even know what this is really all about, but yes, i have experience in big endian architectures, which is why this thread catched my attention. I don't even know what this bin-prot thingy does, do you have a link or something to an explanation ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479152: ITP: core -- Jane Street Capital's alternative standard library for OCaml
On Mon, May 05, 2008 at 08:32:11AM +0200, Stefano Zacchiroli wrote: > On Sun, May 04, 2008 at 09:32:16PM +, Sylvain Le Gall wrote: > > What about patching bin-prot syntax extension to produce "nothing" when > > used... This way, everything still get compiled with "fake" bin-prot... > > I think it will make the required patch smaller (i.e. you will have only > > to patch where the serialization is used and not everywhere). > > Nice idea. Actually it will change what is being patched, as we will > then patch bin-prot rather than core, but this sounds like a good idea. > > Still, it won't be enough to remove completely the need to patch core, > as core has module interfaces which assume that bin-prot has generated > something. One can then think to push your approach further and make > bin-prot generate "assert false" functions rather than nothing, having > static type correctness but runtime errors (which then would become > harder to detect by buildds). Well, it seems like an interesting path, > though not entirely trivial. > > Still, the best would be for bin-prot to support all archs. Maybe we > should wait for the next round of upstream releases? I do hope that > various people will push and/or push for supporting more archs. If > nothing will change, we can move from the current very hackish solution > to yours less hackish solution? (provided we can implement it properly) BTW, i followed this only by far, but have you communicated with upstream about this situation, and what is their opinion on this ? If there is a need to patch cor/bin-proto, maybe the best way is to provide the patch upstream and discuss it with them in order to not need a patch in the future ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dose2_1.2-1_i386.changes REJECTED
On Sat, Apr 26, 2008 at 01:52:12PM +, Joerg Jaspert wrote: > Hi Maintainer, > > rejected, your debian/copyright file is incomplete and misses > (C)holders/license data. You have to include all such differences. > > Like, dose2-ledit/* Hi Joerg, I am just a bystander on this, and have not looked at the package, but i just wanted to point out that the above message is somewhat cryptic and seems incomplete, especially the sentence starting with like, ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how can I prevent cdbs from stripping custom bytecode binaries?
On Wed, Apr 02, 2008 at 10:24:11AM +0200, Stefano Zacchiroli wrote: > On Wed, Apr 02, 2008 at 12:25:41AM +0200, Julien Cristau wrote: > > If you're using cdbs, I believe the proper variable is DEB_STRIP_EXCLUDE > > Indeed that's the recommended way. You can find examples in the > debian/rules of findlib (which does exclude executables by name) and in > galax (which does exclude all executables installed under usr/bin). Should we add this to the policy document ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Block new modules ?
On Mon, Mar 24, 2008 at 08:44:22AM +0100, Stefano Zacchiroli wrote: > On Mon, Mar 24, 2008 at 04:14:54AM +0100, Romain Beauxis wrote: > > I'm currently adding new modules in unstable that are not yet in testing.. > > > > Wouldn't it be a good idea to block them from moving to testing, at least > > until we know if we intent to do the new transition for lenny ? > > Uh? I don't see the reason, your new packages will be built with OCaml > 3.10.1 and can transition with it properly as it is already in testing. > Until we upload 3.10.2 in unstable your modules won't have a dependency > against it and hence won't be entangled in its transition. BTW, just curious, but why don't we upload 3.10.2 to unstable, and upload any further 3.10.1 stuff through lenny-proposed-upgrades or something such ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [proposal] switch our repository from Subversion to Git
On Tue, Mar 11, 2008 at 04:12:53PM +0100, Stefano Zacchiroli wrote: > On Sun, Mar 09, 2008 at 12:49:23PM +0100, Stefano Zacchiroli wrote: > > Yes, but as I've mentioned before, there is a git-specific way of doing > > this, without the need of a hand-made script. > > I was referring to git submodules [1]. However, after a bit of > investigation [2] it seems they are not a handy way of handling multiple > package repository on git.d.o. I've also asked the X.org guys on how > they handle their repositories and it turned out that: > > - you just ask for a group-writable directory on alioth (our will be > /git/pkg-ocaml-maint > > - you don't use it as a git repository, but rather put there a tree with > several git repositories, ours can be something like: > > /git/pkg-ocaml-maint/packages/ # <-- not a git repository > /git/pkg-ocaml-maint/packages/bibtex2html.git/ > /git/pkg-ocaml-maint/packages/cairo-ocaml.git/ > /git/pkg-ocaml-maint/packages/calendar.git/ > ... > /git/pkg-ocaml-maint/projects/ # <-- not a git repository > /git/pkg-ocaml-maint/projects/approx.git/ > /git/pkg-ocaml-maint/projects/debmirror.git/ > ... > ... and so on ... > > - to create a new git repository for a new package you do something > like: > > $ ssh alioth.debian.org GIT_DIR=/git/foo/bar.git git --bare init > --shared=world > > - to manage with just one command the update of several cloned git > repositories the best practice is to use mr [3]. (BTW I think it would > be a wonderful idea to rewrite Sylvain's script about /layout/ to use > mr, as mr is $VCS-agnostic; but of course it is pointless now if we > are going to move to git as it seems) > > - it only remains open the point about how to checkout at once all > package repositories (which probably only myself is interested in > doing, but anyhoe :-)) The solution is mr + ssh alioth.d.o printing > out all the relevant directories > > Yes, it is a bit more cumbersome than the current situation, but nothing > spectacularly hard with a couple of scripts well-documented on our web > page. Also it is working perfectly fine for other I don't see why it > shouldn't for us. BTW, i am curious, why not keep the current svn layout, and use git-svn to access to it, for those who want to use a git like interface and the distributed nature of it ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [proposal] switch our repository from Subversion to Git
On Fri, Mar 07, 2008 at 05:14:13PM +, Sylvain Le Gall wrote: > On 07-03-2008, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > > > > pro/cons of svn -> git > >== > > > > The second new bit is an analysis of the pro/cons of the change. I start > > with mine below, please contribute to the discussion. > > > > Pro > > --- > > > > - Offline work > > Agree > > > - Reduced space requirements > > Agree > > > > > Cons > > > > > > - Add yours here > > I am really not sure we can keep our revision history from Subversion. I > really would like to keep it as far as possible (i.e. history of our > subversion repository). > > If there is a solution for this point, i vote for a migration. > > However, i never have used git -- time to learn. there are at least two tools to import the history, and i think many already use git-svn to work with the svn repositories, there is git import too. As for learning, i long had fear of the learning barrier, even though git is needed for the kernel, but it really is easy to move over. Especially since the git tools tell you what you need to do :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: [Caml-list] OCaml version 3.10.2 released]
On Mon, Mar 03, 2008 at 09:57:10PM +0100, Ralf Treinen wrote: > On Mon, Mar 03, 2008 at 05:23:14PM +0100, Sven Luther wrote: > > On Mon, Mar 03, 2008 at 05:18:28PM +0100, Stefano Zacchiroli wrote: > > > On Mon, Mar 03, 2008 at 10:23:17AM -0500, Eric Cooper wrote: > > > > Understood. I wonder if there is a set of mechanical tests that would > > > > give this answer with high confidence? > > > > > > Sadly I wonder the same and I don't know how to answer. > > > > > > Actually, if even Doligez answers that "he can't guarantee that" I would > > > stay on the safe side and assume "no", but anyhow should feel free to > > > test it and try to convince us all of the contrary ... > > > > Unless things have changed lately upstream, the position upstream has > > always been that there is no binary compatibility between even point > > release, and that we should rebuild everything. This was Xavier Leroy's > > direct answer when i asked him about this back then (in the 3.08 days i > > think), and i think it is a safe bet to assume this is still the case, > > and rebuild everything. This should be relatively little work, as it > > only involved buildd time with the new binNMU scheme, no ? > > And rebuilding by hand the arch=all packages, as long as we don't have > and arch=all autobuilder. > > Since we are trying to push this release into lenny we should probably > play safe and recompile. Also my opinion, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: [Caml-list] OCaml version 3.10.2 released]
On Mon, Mar 03, 2008 at 06:25:36PM +0100, Stefano Zacchiroli wrote: > On Mon, Mar 03, 2008 at 05:23:14PM +0100, Sven Luther wrote: > > Unless things have changed lately upstream, the position upstream has > > always been that there is no binary compatibility between even point > > release, and that we should rebuild everything. This was Xavier Leroy's > > We were discussing this particular reply by Damien: > http://groups.google.com/group/fa.caml/msg/49afe1954b9046bc . Ok, his "may be compatible" sounds a bit unsure though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: [Caml-list] OCaml version 3.10.2 released]
On Mon, Mar 03, 2008 at 05:18:28PM +0100, Stefano Zacchiroli wrote: > On Mon, Mar 03, 2008 at 10:23:17AM -0500, Eric Cooper wrote: > > Understood. I wonder if there is a set of mechanical tests that would > > give this answer with high confidence? > > Sadly I wonder the same and I don't know how to answer. > > Actually, if even Doligez answers that "he can't guarantee that" I would > stay on the safe side and assume "no", but anyhow should feel free to > test it and try to convince us all of the contrary ... Unless things have changed lately upstream, the position upstream has always been that there is no binary compatibility between even point release, and that we should rebuild everything. This was Xavier Leroy's direct answer when i asked him about this back then (in the 3.08 days i think), and i think it is a safe bet to assume this is still the case, and rebuild everything. This should be relatively little work, as it only involved buildd time with the new binNMU scheme, no ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hurry up for 3.10.1
On Sun, Feb 03, 2008 at 08:42:53PM +0100, Samuel Mimram wrote: > Hi, > > Stefano Zacchiroli wrote: > > On Sun, Feb 03, 2008 at 10:04:18AM +0100, Marc 'HE' Brockschmidt wrote: > >> Release schedule > >> > >> Early March 2008 > >> Very soft freeze > >> Please start thinking about the release when uploading new major > >>upstream versions. Only upload to unstable if you are sure that > >>the software will be stable before we release. If you are not > >>convinced, use experimental as staging area. > > > > I think we should hurry up for OCaml 3.10.1, it's a bug fix release > > which for sure we want in Lenny. I think we can go directly for: > > - an upload to unstable of ocaml 3.10.1 > > - a RC bug manually filed against it to avoid transitioning to testing > > until we have checked that everything is fine > > - piecewise upload or binNMU of everything else > > > > What do you think? > > > > For the next week I won't be able to work on this (Sylvain et al: BTW, > > this applies also to my ability to work on ocamlcore.org I presume), > > anyone else can volunteer to upgrade the ocaml package to latest > > upstream? > > I have updated the ocaml package to 3.10.1. Unless someone is against > it, I will upload the new ocaml tomorrow or the day after tomorrow. Go for it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy, location of .cma files in binary packages, and dynlink...
On Thu, Jan 31, 2008 at 09:04:31AM -0500, Eric Cooper wrote: > On Thu, Jan 31, 2008 at 09:37:17AM +0100, Stefano Zacchiroli wrote: > > In an ideal scenario, OCaml would work precisely as it does now for the > > programmer, but store in the finally linked executables and libraries > > only references to objects that will then be loaded dynamically at > > runtime. If that were true, than your analogy with C would stand. > > Unless Xavier has changed his mind, this seems unlikely: > > http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5c365d6671704.en.html I kind of disagree with Xavier on his point 1 : As for feature 1- (smaller executables), I'm not convinced this is a major issue. I'm old enough to remember the introduction of shared libraries in the Unix world (in SunOS 4). At that time, the saving in disk space was significant: disks were small (a complete SunOS 4 install could fit in as little as 100 Mb) and the size of executables wasn't negligible compared to the size of data files. Times have changed, however: disk space has increased much faster than executable sizes, and the disks on a modern machine are mostly filled with data (think MP3 and movies :-), making executable sizes a non-issue. Well, there are various point he is overlooking : 1) This is true for disk space, but what are the impact on memory space ? 2) This is indeed the case for high level desktops or servers, but what about smaller systems, or embedded system, where both memory and disk is sparse. 3) This is also true for disks, but what about diskless setups, and what about setups like the eee pc, or the OLPC, whose system reside on flash disk ? 4) This is true for relatively small number of ocaml apps, and in particular single run ones. What happens if the number of ocaml apps augment, and in particular continuously running apps ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy, location of .cma files in binary packages, and dynlink...
On Mon, Jan 21, 2008 at 09:19:38AM +0100, Stefano Zacchiroli wrote: > On Sun, Jan 20, 2008 at 06:53:38PM +0100, Stéphane Glondu wrote: > > If I understand the Debian OCaml Packaging Policy correctly, .cma files > > should be in libxxx-ocaml-dev binary packages. Has this choice been > > taken with dynamic loading in mind? > > No, it has not. The reason being, I would say, in one of the most > annoying language deficiency (or of its marketing, doesn't matter), > namely: discouraging as much as possible dynamic loading at the point > that basically no program does dynamic loading. > > I'm glad that Ocsigen finally raise the issue ... > > > Ocsigen may, and does with its default configuration and in the most > > useful cases, dynamically load nums.cma, sqlite3.cma, and > > cryptokit.cma, the last two being in *-dev packages. However, I think > > this is confusing: is it ok for an executable to depend on *-dev > > packages at runtime? > > Well, the *-dev naming is just a convention, OCaml *-dev package are not > necessarily related to the C *-dev packages mentioned in the legacy > Debian policy so if we want ... we can do that. Sure it would be not a > nice-looking practice, to everyone a -dev suffix will look like as > something for, well, dev-elopers! > > > When OCaml with native dynamic loading is realeased, where so-called > > "plugins" (.cmxs, I am not talking about .cmx files!) should be put? > > libxxx-ocaml or libxxx-ocaml-dev? The second choice would be > > meaningless, since .cmxs are only meant to be dynamically loaded. And > > the first choice would be inconsistent with the current choice for .cma > > files. > > The point you're raising is indeed quite deep. Thinking about it I came > to the conclusion that our current distinction between libxxx-ocaml and > libxxx-ocaml-dev is quite broken. Indeed, what should be part of the one > and what of the other? The following I think are undebatable: > > libxxx-ocaml: > - shared objects for dynamic loading of C stubs > > libxxx-ocaml-dev: > - developer documentation > - *.mli (and *.ml, if really wanted) > - META files and other build tool support files, stub generators, ... Do we have some statistics about the size of each of these packages ? If the size is not such an impact, we can just drop the -dev version. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy, location of .cma files in binary packages, and dynlink...
On Mon, Jan 21, 2008 at 09:21:01AM +0100, Stefano Zacchiroli wrote: > On Sun, Jan 20, 2008 at 10:42:10PM +0100, Sven Luther wrote: > > If ocaml dynamic linking is now going to happen, the policy should be > > adapted, and the separation will always be that whatever is needed at > > runtime goes into the * package, and what is needed only at build time, > > should go into the -dev packages. > > With the problem that it is no longer sharp clear what goes where, see > my post for the details, but you no longer knows whether at runtime only > a .so is needed or also a bunch of .cma. I don't believe that what is used is so undeterministic. But anyway, in the case of dynamic loading, everything which *can* be needed at runtime. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy, location of .cma files in binary packages, and dynlink...
On Sun, Jan 20, 2008 at 06:53:38PM +0100, Stéphane Glondu wrote: > Hi, > > If I understand the Debian OCaml Packaging Policy correctly, .cma files > should be in libxxx-ocaml-dev binary packages. Has this choice been > taken with dynamic loading in mind? > > Ocsigen may, and does with its default configuration and in the most > useful cases, dynamically load nums.cma, sqlite3.cma, and cryptokit.cma, > the last two being in *-dev packages. However, I think this is > confusing: is it ok for an executable to depend on *-dev packages at > runtime? > > When OCaml with native dynamic loading is realeased, where so-called > "plugins" (.cmxs, I am not talking about .cmx files!) should be put? > libxxx-ocaml or libxxx-ocaml-dev? The second choice would be > meaningless, since .cmxs are only meant to be dynamically loaded. And > the first choice would be inconsistent with the current choice for .cma > files. > > Therefore, I think .cma files should be put in libxxx-ocaml binary > packages instead, or at least this possibility should be allowed and > explicitly mentioned in the policy. Well, when the policy was written, ocaml dynamic linking was still a dream few foresaw happening in the near future. If ocaml dynamic linking is now going to happen, the policy should be adapted, and the separation will always be that whatever is needed at runtime goes into the * package, and what is needed only at build time, should go into the -dev packages. But you speak of it in the future ? Do you have an idea of when such a new release will happen ? The question being how far debian will be with the lenny release that it may be included or not. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [binNMU] facile
On Wed, Sep 12, 2007 at 04:11:14PM -0700, Steve Langasek wrote:
> On Wed, Sep 12, 2007 at 08:47:19PM +0200, Sven Luther wrote:
> > On Wed, Sep 12, 2007 at 10:42:55AM -0700, Steve Langasek wrote:
> > > On Wed, Sep 12, 2007 at 11:35:07AM +0200, Stefano Zacchiroli wrote:
>
> > > > I was just wondering if anything can be improved on the handling of
> > > > that give backs (on which I'm sure you know more than me). Knowing that
> > > > with non timely upload I can induce some troubles to others is not
> > > > exactly something I like :) But maybe this is not the right thread to
> > > > discuss this stuff ...
>
> > > Sure, there's room for improvement here. One of the optimizations that's
> > > been discussed in the past would be to auto-dep-wait packages on the
> > > newest
> > > version of all build-dependencies to enforce build ordering, but I don't
> > > think we have any kind of hard numbers on new problems this might
> > > introduce
> > > (unnecessary transition delays, etc).
>
> > It seems to me that this is the kind of problems, that we faced with the
> > ocaml packages since years. On the pure dependency, this was achieved
> > with the abi provides, but for the ocaml package alone.
>
> > Maybe something similar could be achieved for the other packages,
> > generated in a semi-automated way, or maybe an abi-field or something
> > should be added.
>
> > Ralf, you are involved with the EDOS folk, which if i remember well,
> > this kind of stuff has been one of the topics they where involved with.
>
> I'm not sure what problem you're trying to solve here. The problem at hand
> is "what other packages need to be rebuilt first because they also depend on
> the same {library/runtime} package as the present package." That should be
> solvable without adding any new fields at all.
Sylvain replied to this, in better words that i could currently do, it
has been a long time that i was involved in this, and my debian time has
been (and continues sadly to be) overshadowed by political and
witch-hunt stuff.
Think of all what could have been achieved in debian if it was a bit
more open, and DDs didn't lose so much time in stupid, sterile and
destructive flamewars :/
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [binNMU] facile
On Wed, Sep 12, 2007 at 10:42:55AM -0700, Steve Langasek wrote: > On Wed, Sep 12, 2007 at 11:35:07AM +0200, Stefano Zacchiroli wrote: > > > I was just wondering if anything can be improved on the handling of > > that give backs (on which I'm sure you know more than me). Knowing that > > with non timely upload I can induce some troubles to others is not > > exactly something I like :) But maybe this is not the right thread to > > discuss this stuff ... > > Sure, there's room for improvement here. One of the optimizations that's > been discussed in the past would be to auto-dep-wait packages on the newest > version of all build-dependencies to enforce build ordering, but I don't > think we have any kind of hard numbers on new problems this might introduce > (unnecessary transition delays, etc). Hi Steve, ... It seems to me that this is the kind of problems, that we faced with the ocaml packages since years. On the pure dependency, this was achieved with the abi provides, but for the ocaml package alone. Maybe something similar could be achieved for the other packages, generated in a semi-automated way, or maybe an abi-field or something should be added. Ralf, you are involved with the EDOS folk, which if i remember well, this kind of stuff has been one of the topics they where involved with. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 3.10.0 transition status
On Mon, Sep 10, 2007 at 04:12:47PM +0200, Stefano Zacchiroli wrote: > On Mon, Sep 10, 2007 at 02:06:04PM +0200, Sven Luther wrote: > > U after the name, means that those packages are group maintained or > > something, right ? > > Right. > > $ man dd-list > > > What is the strategy on those ? > > I would say to pint the most recent uploader (as I did with the BCc) and > wait some days. If noone will act we should split them among us and do > the work ... These packages where already uploaded to experimental, so the only work needed is tagging and uploading ? Or is there something else i can help with ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 3.10.0 transition status
On Mon, Sep 10, 2007 at 01:59:27PM +0200, Stefano Zacchiroli wrote: > On Wed, Aug 29, 2007 at 09:57:52PM +, Sylvain Le Gall wrote: > > http://wiki.debian.org/Teams/OCamlTaskForce/Transition3-10-0 > > I've changed the format of this page, now it lists the "TODO" packages > which still need to be transitioned. It mainly contains a dd-list of the > packages in need of work. > > Please have a look at your packages or ask here for help in case you > can't work on your package. > > [ BCc-ing some of the people whose packages need to be transitioned ] U after the name, means that those packages are group maintained or something, right ? What is the strategy on those ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what should we do about confluence?
On Mon, Sep 03, 2007 at 09:53:40PM +0200, Ralf Treinen wrote: > Hello, > > the package "confluence" is orphaned, and build-depends on ocaml, so we > could consider adopting it by the team. The orphaning message is here: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418965 > > This message says that "confluence" is superseeded by a new project > called HDCaml. Looking around on the web I find that HDCaml in turn has > been abandonend too, and is now replaced by a project called "atom" > (http://funhdl.org/wiki/doku.php/atom) - which aparently is written > in Haskel ... > > Popcon count is quite low (60 installations). What should we do about it? > Gildor just says on #debian-ocaml: > > i think you should leave a README.Debian stating this package has only > been adopted by d-o-m for rebuilding it, but that it will be dropped if > there is RC bugs on it > > I guess that is what I am going to do, and put debian-ocaml-maint as > maintainer. Any other opinions on that? You should open a bug against wnnp or whatever it is with a request-for-help^tag (RFH). This will appear in the bug report, and in the PTS. MAybe even clone that bug and reassign it to the package ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 3.10: time to upload to unstable (!?)
On Sat, Aug 18, 2007 at 01:22:05PM +0200, Julien Cristau wrote: > On Sat, Aug 18, 2007 at 13:14:08 +0200, Stefano Zacchiroli wrote: > > > Hi guys, > > I think is time to go ahead and start uploading 3.10 stuff to > > unstable. Not yet has been rebuilt in experimental, but I believe the > > major showstopper have been, and we have fallbacks for the potentially > > problematic issue of the new camlp4. > > > +1 from me (although I probably won't have much time to help). I am all for it too, altough obviously i can't help to upload stuff. I can give a hand to investigate problematix stuff and coordinate, but as i understand this work is already done. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming scheme for coq libraries
On Thu, Aug 09, 2007 at 10:36:27AM +0200, Samuel Mimram wrote: > Hi, > > Sven Luther wrote: > > On Thu, Aug 09, 2007 at 09:38:16AM +0200, Samuel Mimram wrote: > >> Hi, > >> > >> I've had a bug report (#430878) which has asked me to package the Float > >> library for coq. Since it is the first coq library to be packaged, we > >> have to decide of a naming scheme for those. I would go for > >> "coq-lib-float" but if anyone has a better / more standard suggestion > >> for the name of the package, it's time to say it... > > > > libcoq-float ? To be consistent with the libocaml-foo naming scheme ? > > Ah, right, it should be libfloat-coq then to be consistent with caml's > scheme. Any other suggestion? I prefer the lib(coq|ocaml)-float kind of names myself, but well, ocaml is saddled with the historical choice we did back then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming scheme for coq libraries
On Thu, Aug 09, 2007 at 09:38:16AM +0200, Samuel Mimram wrote: > Hi, > > I've had a bug report (#430878) which has asked me to package the Float > library for coq. Since it is the first coq library to be packaged, we > have to decide of a naming scheme for those. I would go for > "coq-lib-float" but if anyone has a better / more standard suggestion > for the name of the package, it's time to say it... libcoq-float ? To be consistent with the libocaml-foo naming scheme ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: commit access right for all DDs to our repository
On Thu, Jul 26, 2007 at 06:10:47PM +0200, Stefano Zacchiroli wrote: > On Thu, Jul 26, 2007 at 05:48:08PM +0200, Sven Luther wrote: > > The commits are still send to the list, so we would just need to add a > > tag in fron of the topic. maybe [NMU] or something. > > Ok for the tag, but notice that commits are sent to a separate list. I'm > also proposing to send [NMU] commits to the discussion list, in the same > spirit of the NMU notifications which get delivered to Maintainers of > NMU-ed packages. > > > I don't know how ACL work, but maybe it is easily to distiguish > > between team members and outsiders with it, no ? > > It's nothing special: users can write to a file as if the had write > permissions. So we will see the user name of the commiter and we would > just need to compare it with the *nix group matching our project. > > > Furthermore, i don't remember what the current concesnsus is, but would > > this not be the time to split the mailing list between d-o and d-o-m ? > > With the bug reports and svn commits going to d-o-m, and general > > discussion like this one staying on d-o (and a possible future d-i-devel > > splitoff if we ever need a pure user list). > > It's already as this. Discussion d-o-m, commits to > [EMAIL PROTECTED] or similar. The fact the mailing list is > called d-o-m is now not really standard wrt to other lists, but I don't > see the point of changing it at this point in our history. Ah, ok, they both go in the same mail box for me, so i didn't remember which got where. The idea of creating d-o for discussion, and commits + bug reports to d-o-m would allow to keep the group maintenance emails to stay as is, and still send it to the work list, and not the discussion list, but as you said, the current situation seems fine. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: commit access right for all DDs to our repository
On Thu, Jul 26, 2007 at 05:39:41PM +0200, Stefano Zacchiroli wrote: > On Thu, Jul 26, 2007 at 05:13:08PM +0200, Sven Luther wrote: > > Yes, go for it. This is indeed the way to go, but we must make sure that > > non-member commit logs are marked in a way allowing us to double check > > it, be it only because an outsider will be more able to make mistake or > > so. > > Any idea about how to achieve this? My best attempt (but I'm not > volunteering to implement it :-)) would be a commit hook which checks > the committer and, if it is not part of the project then it send the > commit notification to the package maintainer *and* to this list in > order to increase the number of eyes which can review the commit. The commits are still send to the list, so we would just need to add a tag in fron of the topic. maybe [NMU] or something. I don't know how ACL work, but maybe it is easily to distiguish between team members and outsiders with it, no ? Furthermore, i don't remember what the current concesnsus is, but would this not be the time to split the mailing list between d-o and d-o-m ? With the bug reports and svn commits going to d-o-m, and general discussion like this one staying on d-o (and a possible future d-i-devel splitoff if we ever need a pure user list). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: commit access right for all DDs to our repository
On Thu, Jul 26, 2007 at 04:39:52PM +0200, Stefano Zacchiroli wrote: > Hi Camlers, > the collab-maint project on alioth enables (using ACLs) all DD > accounts on alioth to have commit access right to the repository. > > In the spirit of diminishing the sense of "ownership" of packages in our > distribution, and to gain other side effect benefits (e.g. the fact that > NMU patches can be directly committed in a repository) I'm hereby > proposing to require a similar setup for our repository. Of course the > same spirit of NMUs will govern the changes and DDs willing to commit > stuff are required (moral suasion) to document their changes in > debian/changelog. > > Practically, I don't think this will change anything in our way of > working and I doubt that anyone else will feel the need to commit stuff, > but I believe this is the right way to go for the Debian project as a > whole, and I hence hope our project will be among the firsts in adopting > this policy. > > The technical change is trivial, and can be requested by simply mailing > the alioth admins. > > Will anyone object such a change for our repository? Yes, go for it. This is indeed the way to go, but we must make sure that non-member commit logs are marked in a way allowing us to double check it, be it only because an outsider will be more able to make mistake or so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: camlp4s_4.03-1_i386.changes REJECTED
On Wed, Jul 18, 2007 at 12:03:14AM +0200, Joerg Jaspert wrote: > On 11083 March 1977, Sven Luther wrote: > > >> you want to check your files again and fix debian/copyright. And/Or talk > >> to Upstream about the license of at least /ocaml_stuff/* - it is the > >> broken QPL, not BSD. > > > Notice that the ocaml_stuff stuff is taken from the ocaml packages, > > which are under a modified QPL with exception to satisfy debian, > > so there is absolutely no problem here.o > > > Maybe one could just keep the ocaml version actually used in ocaml, and > > drop the older versions which predate the change, or more logically, > > make camlp4s use the ocaml based files we package in ocaml-libs or > > whatever it was. > > > Joerg, since those files are verbatim copies of what we have in the > > archive anyway, i don't see where the problem is ... > > If it is something modified that actually works for the archive - Sure, it is, look at the archive of debian-legal about ocaml and the QPL for details. > fine. I dont care. But It still needs to get into the copyright file, > which it wasnt. The best idea would be to drop those files altogether and use the one from the specially done for this purpose package instead, but this would be an unneeded burden. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: camlp4s_4.03-1_i386.changes REJECTED
On Tue, Jul 17, 2007 at 07:09:11PM +, Joerg Jaspert wrote: > Hi Maintainer, > > you want to check your files again and fix debian/copyright. And/Or talk > to Upstream about the license of at least /ocaml_stuff/* - it is the > broken QPL, not BSD. Notice that the ocaml_stuff stuff is taken from the ocaml packages, which are under a modified QPL with exception to satisfy debian, so there is absolutely no problem here.o Maybe one could just keep the ocaml version actually used in ocaml, and drop the older versions which predate the change, or more logically, make camlp4s use the ocaml based files we package in ocaml-libs or whatever it was. Joerg, since those files are verbatim copies of what we have in the archive anyway, i don't see where the problem is ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploaders automatically set to the last nth workers on a pkg
On Mon, Jul 16, 2007 at 11:10:47AM +0200, Stefano Zacchiroli wrote: > > Since the maintainer is the mailing list, the ocaml packages are > > automatically attributed as co-maintainership to each uploader. If you > > get dropped from it, because you didn't upload it in some time or > > whatever, they will automatically be dropped from the PTS > > package-per-maintainer page, thus giving you less overview of the > > packages you care about. > > The assumption of all this is that the concept of "package you care > about" is the same as "packages you did something for". With the > reasoning above you're breaking this assumption. > > Also it seem to me that it's bringing us out of track: the goal of the > PTS is monitoring the packages you're working on, not the packages > you're interested in as a "lurker". Well, i consider all the packages i used to maintain as still at least partly mine, even though i have been forced into the "lurker" role, both by the sad events of last year which made things difficult for me, and vastly killed my motivation, and by generally having to work for RL money and sustaining my family, and thus having less time for debian. I know my case is special given the witch hunt i was the subject of, but this make me think about such corner case, and i have still hope that some day debian will wake up, and behave humanly, but hey ... > > If you could configure and organise the ppackage-per-maintainer PTS > > page, you could simply add packages you are interested in and not > > uploader, and this would not be a problem. > > This would be a reasonable feature request for the PTS, but (knowing how > it's implemented) not easy to add ... :) > > I don't think you understood me right, or else i didn't understand yoru > > answer (or both :)). > > Indeed, it was my understanding that you was pointing to some technical > incompatibility between this idea and the PTS way of handling Uploaders, > I hope we are better understanding each other now. Nope, but maybe Sylvain said it better than me :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploaders automatically set to the last nth workers on a pkg
On Mon, Jul 16, 2007 at 09:34:41AM +0200, Stefano Zacchiroli wrote: > On Mon, Jul 16, 2007 at 07:44:09AM +0200, Sven Luther wrote: > > Notice that this will automatically drop me from uploaders, which i > > Well, not necessarily. You have an alioth account, and even if it gets > dropped you can have a -guest alioth account. With that you can > work/commit in our repository. > > At that point the policy would be fair with everyone: the last nth > people who worked on a package will be listed. It's just up to you to > decide whether you want to work on which packages or not. Ah, hadn't though about that, but notice that the changelog entry will be attributed to the guy who lastly edit it, which is usually the guy who uploads the package (thus not me). Does the script take into account sub-entries in the changelog or only the main entry name ? That said, in this automated world, can we easily distinguish between a contributor which should be uploader, and one which is a mere contributor ? > > Another impact is the effect of removing the uploader field on the PTS > > pages, but this should probably be solved by a more configurable PTS > > page (where you could list the packages which interest you, probably > > in different order and groupping even). > > Uhm, why so? The Uploaders information is in the Sources file, and it's > just a matter of uploading the correct debian/control. It seems to me > that the Gnome guys are using a control.in (as we do in some OCaml > packages), it's just a matter of relying upon it ... (I understand it > can be a nuisance though). The PTS will list all packages you are a maintainer for, as well as those you are uploader. Since the maintainer is the mailing list, the ocaml packages are automatically attributed as co-maintainership to each uploader. If you get dropped from it, because you didn't upload it in some time or whatever, they will automatically be dropped from the PTS package-per-maintainer page, thus giving you less overview of the packages you care about. If you could configure and organise the ppackage-per-maintainer PTS page, you could simply add packages you are interested in and not uploader, and this would not be a problem. I don't think you understood me right, or else i didn't understand yoru answer (or both :)). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploaders automatically set to the last nth workers on a pkg
On Fri, Jul 13, 2007 at 01:16:03PM +, Sylvain Le Gall wrote: > On 13-07-2007, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote: > > Quoting from http://www.lucas-nussbaum.net/blog/?p=245: > >> Another variant is pkg-kde and pkg-gnome’s automatic generation of the > >> Uploaders field based on the last X entries of debian/changelog > >> (pkg-kde variant, pkg-gnome variant).) > > > > This is an interesting idea, and they both already have cdbs snippets > > for doing that, what do you think of this idea? > > > > I like our current scheme of having this list as maintainer and the > > Uploaders field set to who "usually works" on a package, but adding > > automatic updated of this latter part is something I would like to have. > > > > Can I go forward and it to our CDBS class? > > Comments? > > > > I think it is a great idea -- better than the way we actually fill the > Uploaders fields. Notice that this will automatically drop me from uploaders, which i cannot like in a kind of political way given the current mess, but hey, ... Another impact is the effect of removing the uploader field on the PTS pages, but this should probably be solved by a more configurable PTS page (where you could list the packages which interest you, probably in different order and groupping even). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new web page: overview of OCaml related packages / transitions
On Thu, Jul 12, 2007 at 04:18:24PM +0200, Stefano Zacchiroli wrote: > On Thu, Jul 12, 2007 at 09:25:07AM -0400, Mike Furr wrote: > > How does it handle different architectures? E.g. does it show a package > > being built if it exists on at least 1 arch, or does it have to be built on > > all arches? For transitions, we clearly need the latter. Also, a nice > > At the moment it only takes into account i386. I thought about that page > to spot which packages need to be transitioned at all (i.e. which > packages no one has yet taken care of). Questions like: why the package > is not in testing yet can be answered by other means. > > Still: > > 1) the links about the relevant pages can and should be put, what do you >think of a link for each package to its "explained excuses" page? >Any other per-package link which can be useful? What about a link to the PTS, so you get indirect access to everything there ? > 2) considering other architectures is still useful, for example ATM if >someone uploads to powerpc and the rebuild breaks on i386 we will be >fooled to consider the package as needing work, while it's not the >case. I can implement a check which looks in all architectures and >only takes into the account the more up to date. Once I had to >implement it adding a warning like "hey, the package is not in sync >on ..." would be easy to add Maybe with a different colour code ? > > thing for the TODO list would be to list the packages that are not up to > > date, but have all of their dependencies satisfied on all arches. > > Are you thinking about pinging buildd maintainers to reschedule builds > here? Isn't this information already available somewhere else, maybe for > all packages in the archive? Possibly, but it is always good to have a tool which does it in a way we control :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new web page: overview of OCaml related packages / transitions
On Thu, Jul 12, 2007 at 12:04:08PM +0200, Stefano Zacchiroli wrote: > Hi all, > yesterday I got impressed by the "Status of GNOME packages in Debian" > page that the GNOME maintainers are using for their transition. So I > wanted to have something like that for OCaml and this night I've created > it :) > > The current result can be seen here: > > http://sockmel.bononia.it/~zack/ocaml-debian-status/debian-ocaml-status.html > > Unfortunately it can be moved to alioth directly since the cron job > generating it requires some dependencies which are not available on > alioth, I hope this can be fixed soon. > > In the meantime I've added a link to it from our homepage on alioth > (http://pkg-ocaml-maint.alioth.debian.org/) and the code which generates > the page is available in our repository (tools/ocaml-debian-status/). > Note that ATM testing is not taken into account because Packages of > testing are currently broken (i.e. non-822 compliant) in our archive, > and this breaks the 822 parser I'm using. > > As you can see from the table we have quite a bit of work to do for > OCaml 3.10.0 ... go for it! :-P Nice work Stefano, ... Just a little question for the color scheme. The different green shades are a bit difficult to distinguish. I guess you can note the difference between the experimental and the unstable ones, but from a first sight they all look almost uniformously green, and even after a second look, they kind of make your mind wonder if they are uniform or not, which is auite head-ache inducing (but granted, i had less than 4 hours sleep this night :). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 1st incompatibility with 3.10 (ledit): let's package camlp4s?
On Fri, Jul 06, 2007 at 04:53:43PM +0200, Stefano Zacchiroli wrote: > Quoting (and rearranging) text from myself: > > ledit (1.13-3) UNRELEASED; urgency=low > > * BIG FAT WARNING: ledit does not build against the new camlp4, we will > need > one of: > 1) packaging camlp4s (http://cristal.inria.fr/~ddr/) > 2) porting ledit to the new camlp4 > 3) dropping ledit from the archive Another alternative would be porting ledit to plain ocaml. All camlp4* stuff are evil anyway :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 1st incompatibility with 3.10 (ledit): let's package camlp4s?
On Fri, Jul 06, 2007 at 07:54:20PM +0200, Claudio Sacerdoti Coen wrote: > > The only choice which is not a good solution is "2)" since, it requires > > work that is quite complicated to do if upstream doesn't agree. > > Well, not really (at least in theory). > You can just run the old camlp4 once to translate the source to standard > syntax and then package the translated sources. In principle this could > be done at every new upstream release. It could be bad debian practice, > though. > How readable is the translated source ? Notice that if the ledit licence is GPLish, we may violate the refered form of modification requirement by doing this. That said, there was no development on ledit upstream since over 4 years, but i see that there was in the last few months. Was this more than just cosmetic changes ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 1st incompatibility with 3.10 (ledit): let's package camlp4s?
On Fri, Jul 06, 2007 at 04:53:43PM +0200, Stefano Zacchiroli wrote: > Quoting (and rearranging) text from myself: > > ledit (1.13-3) UNRELEASED; urgency=low > > * BIG FAT WARNING: ledit does not build against the new camlp4, we will > need > one of: > 1) packaging camlp4s (http://cristal.inria.fr/~ddr/) > 2) porting ledit to the new camlp4 > 3) dropping ledit from the archive > > Having read DDR's statement on the caml mailing list I'm pretty sure he > will never port ledit to the new camlp4. > > We can do (2) in Debian, but I think it's pointless, we have > alternatives to ledit and it would also practically mean forking ledit. Notice, that until something happened in the recent times, i don't remember any upstream development to ledit. > We can do (3), which is reasonable precisely because we have > alternatives. Can you tell us which are the alternatives ? When i originally packaged ledit, nothing came really near, but i have not been following this stuff since then. > Or we can do (1), which might prove useful as I guess not every piece of > camlp4-related software will be ported to the new one, given that the > old one is available. > > Therefore I'm in favour of (1) (still, I haven't yet looked at binary > name conflicts or similar issues...), what do you think? I vote for (1) too. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: do we still need ocamldot in the ocaml-tools package?
On Sat, Jun 23, 2007 at 07:51:41PM +0200, Ralf Treinen wrote: > Hello, > > the ocamldot program is currently part of the ocaml-tools package. > For those of you who do not know it: it constructs a dependency graph > of modules in the dot format which can then be displayed by the > graphviz tools. This fucntionality is provided by ocamldoc since > some time (since vesion 3.05 of ocamldoc, according to the ocmaldot > home page). Invocation is slightly different, with ocamldot you would do > > ocamldep *.ml | ocamldot > dep.dot > > while with ocamldoc you need to have compiled the interfaces of the > modules, and then you do an > > ocamldoc -dot -o dep.dot *.ml > > The graph layout seems to be slightly different too, but besides this > the fucntionalities are the same as far a I can see. Hence, I plan to > drop ocamldot from the next uplaod of ocaml-tools. Are there any > objections? Seems fine to me, i guess this means that ocamldot is no longer really maintained anyway, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421052: ocaml-sqlite3 - FTBFS: ocamlopt: Command not found
On Thu, Apr 26, 2007 at 07:32:21AM +0200, Bastian Blank wrote: > Package: ocaml-sqlite3 > Version: 0.16.0-1 > Severity: serious > > There was an error while trying to autobuild your package: > > > Automatic build of ocaml-sqlite3_0.16.0-1 on debian-31.osdl.marist.edu by > > sbuild/s390 98 > [... ] > > make[1]: Entering directory `/build/buildd/ocaml-sqlite3-0.16.0' > > ocamlc -pp camlp4o -c sqlite3.mli > > ocamlopt -pp camlp4o -c sqlite3.ml > > make[1]: ocamlopt: Command not found > > make[1]: *** [sqlite3.cmx] Error 127 > > make[1]: Leaving directory `/build/buildd/ocaml-sqlite3-0.16.0' > > make: *** [install] Error 2 > > ** > > Build finished at 20070425-0516 > > FAILED [dpkg-buildpackage died] s390 doesn't support the native code compiler, so ocamlc should have been chosen. I suppose ocaml-sqlite3 does not support proper ocamlopt checking, is thus violating the ocaml policy, and will fail on other non-native arches (m68k, ...) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#415194: libextlib-ocaml-dev: No debugging information
On Mon, Apr 09, 2007 at 03:52:41PM +0200, Stefano Zacchiroli wrote: > On Mon, Apr 09, 2007 at 03:12:48PM +0200, Sven Luther wrote: > > This would strongly hint at a behaviour of always including the debug > > symbols > > in libraries, and since the .cmo/.cma are in the -dev file anyway, this > > would > > not impose a size penalty on the normal user at all. > > > > Do we have an idea of how much the size increase is ? > > I tested that on extlib, and I'm quite scared by the result: > > [EMAIL PROTECTED]:$ ls -l *deb > -rw-r--r-- 1 zack zack 297300 2007-04-09 15:27 > libextlib-ocaml-dev_1.5-6_i386.deb > -rw-r--r-- 1 zack zack 529000 2007-04-09 15:34 > libextlib-ocaml-dev_1.5-7_i386.deb > > As expected the changelog entry for -7 is: > > [EMAIL PROTECTED]:$ dpkg-parsechangelog | tail -2 > * compile objects with debugging information, patch from Ivan Jager >(Closes: #415194) > > Some more details: > > [EMAIL PROTECTED]:$ dpkg --info *-6*.deb | grep -i size >size 297300 bytes: control archive= 4908 bytes. >Installed-Size: 1808 > [EMAIL PROTECTED]:$ dpkg --info *-7*.deb | grep -i size >size 529000 bytes: control archive= 4907 bytes. >Installed-Size: 2280 > [EMAIL PROTECTED]:$ dpkg-deb -x *-6*.deb no_debug/ > [EMAIL PROTECTED]:$ dpkg-deb -x *-7*.deb debug/ > [EMAIL PROTECTED]:$ du -sh no_debug/usr/lib/ocaml/3.09.2/extlib/ > 840Kno_debug/usr/lib/ocaml/3.09.2/extlib/ > [EMAIL PROTECTED]:$ du -sh debug/usr/lib/ocaml/3.09.2/extlib/ > 1,3Mdebug/usr/lib/ocaml/3.09.2/extlib/ > > About 50% more in the size of OCaml objects, that's *a lot*. IMO this is > enough of an argument to give up the idea, and also to strip the > standard library, but maybe we should ask for the opinions of the > release managers / the cd team. Well, it is a huge size increase, but how many libraries are affected ? What is the size of all the ocaml bytecode libraries in the archive ? And if you compare that to the -dbg versions of the C libraries, is it significant ? I am still in favour of always including them, i was told some time ago by someone close to the ftp-masters, that even the place gain of not rebuilding coq for all non-native arches was a minor issue, so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#415194: libextlib-ocaml-dev: No debugging information
On Mon, Apr 09, 2007 at 03:03:47PM +0200, Stefano Zacchiroli wrote: > On Mon, Apr 09, 2007 at 02:59:39PM +0200, Sven Luther wrote: > > One interesting question here, is what is the cost of adding those debugging > > symbols ? > > Quoting from the OCaml manual (3.09) [1]: > > > Before the debugger can be used, the program must be compiled and > > linked with the -g option: all .cmo and .cma files that are part of > > the program should have been created with ocamlc -g, and they must be > > linked together with ocamlc -g. > > > > Compiling with -g entails no penalty on the running time of programs: > > object files and bytecode executable files are bigger and take longer > > to produce, but the executable files run at exactly the same speed as > > if they had been compiled without -g. > > So: no runtime penalty, only size increase. (Of course I'm speaking > module the increased time the interpreter will need to load a bigger > caml object, but that should be negligible most of the time). So, this means there is no runtime cost, and only a size increase. And i suppose that if you link the binary without -g, then the debugging symbols are not included in the final binary, which would be the behaviour Julien mentioned. This would strongly hint at a behaviour of always including the debug symbols in libraries, and since the .cmo/.cma are in the -dev file anyway, this would not impose a size penalty on the normal user at all. Do we have an idea of how much the size increase is ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#415194: libextlib-ocaml-dev: No debugging information
On Mon, Apr 09, 2007 at 11:58:03AM +0200, Stefano Zacchiroli wrote: > [ Ob: debian-ocaml-maint, look at the end of this mail ] > > tags 415194 + wontfix > thanks > > On Fri, Mar 16, 2007 at 06:55:27PM -0400, Ivan Jager wrote: > > The bytecode files are currently compiled without debugging support. > > This makes it hard to debug other code that might be called by it. Eg, a > > function passed to List.iter. > > In the Debian folklore of libraries (at large, not OCaml-specific) > that's a feature, not a bug. Indeed usually libraries do not contain > debugging symbols and where is deemed appropriate an extra -dbg library > package is built containing debugging information. > > > Since the standard libraries are compiled with debugging support it > > seems like it would make sense to do the same for others. Yes, it might > > be slightly slower, but anyone who cares about speed will probably be > > compiling native code anyways. > > In the specific case of OCaml libraries I think we never discussed the > issue and therefore I think the standard libraries just happen to be > compiled that way (probably because they are compiled that way upstream) > without any particular reason. > > So, at the moment I'm tagging this bug report as wontfix, but diverting > the more general question of "should we mandate inclusion of debugging > symbols in OCaml bytecode libraries"? to the debian-ocaml-maint mailing > list. On one hand we should be consistent with the general library > philosophy of not including debugging symbols in packages other than > -dbg. On the other it is true that a user willing to have performances > will use native code libraries, but is still true that native code > libraries are not available everywhere ... One interesting question here, is what is the cost of adding those debugging symbols ? Is this cost a performance hit, or only a size increase ? Is anyone familiar with how debugging is implemented in ocaml ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: After the release: ocaml 3.09.3 or 3.10.0 ?
On Sun, Apr 01, 2007 at 10:20:12AM +0200, Stefano Zacchiroli wrote: > On Sun, Apr 01, 2007 at 07:35:57AM +0200, Sven Luther wrote: > > What is the status of ocaml with regard to the etch release ? Everything is > > in > > testing, and etch is frozen anyway, so we could start uploading 3.09.3 to > > sid > > asap, and use t-p-u in case a bugfix is needed for etch ? > > Yes. I guess we are just missing someone with enough time to do that :) > If you're willing to please go ahead, I'll be happy to sponsor the > upload afterwards. Bah, if i do the work, i will do the upload, even if i have no right to it, and let the ftp-master handle the mess afterward. This was all a political maneuver anyway to stop me from running as DPL, and it worked, i should probably not have retired my candidature like i did. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: After the release: ocaml 3.09.3 or 3.10.0 ?
On Sat, Mar 31, 2007 at 10:41:25PM +, Sylvain Le Gall wrote:
> Hello,
>
> On 31-03-2007, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote:
> > On Fri, Mar 30, 2007 at 10:36:56PM +, Sylvain Le Gall wrote:
> >> Well, i am just asking myself if we will really release 3.09.3 since
> >> 3.10.0 seems to come soon ?
> >
> > Given the subject I guess you were meaning not "release" but rather what
> > to "package" after the release. Of course 3.10.0!
> >
>
> Maybe, i don't understand the difference, but we have "almost" package
> 3.09.3, since it is standing in experimental according to
> http://packages.debian.org/experimental/devel/ocaml
> (this is 3.09.3 rc1 but AFAIK there is not a big difference with 3.09.3)
>
> So since, we have package it, i was asking if we will upload this
> package to unstable ("upload a package" is maybe more clear than release
> a package version).
>
> But, i agree with you, that we should jump to 3.10.0.
What is the status of ocaml with regard to the etch release ? Everything is in
testing, and etch is frozen anyway, so we could start uploading 3.09.3 to sid
asap, and use t-p-u in case a bugfix is needed for etch ?
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Meta-ocaml
On Sat, Mar 31, 2007 at 09:21:48AM +0200, Jérôme Marant wrote: > Le samedi 31 mars 2007, Sven Luther a écrit : > > On Fri, Mar 30, 2007 at 10:04:04PM +0200, Jérôme Marant wrote: > > > Hi, > > > > > > It looks like I'm still listed in the meta-ocaml package uploaders. > > > I just left the project so I guess the email address will bounce anytime > > > soon. > > > > > > Thanks in advance for removing it. > > > > You left debian ? > > Yes, I did. But since you can't read debian-private any more, you couldn't > have > known it. Yes, i know. Sad to see you go, and i wish you good luck in whatever you are now doing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: After the release: ocaml 3.09.3 or 3.10.0 ?
On Fri, Mar 30, 2007 at 10:36:56PM +, Sylvain Le Gall wrote: > Hello all, > > Well, i am just asking myself if we will really release 3.09.3 since > 3.10.0 seems to come soon ? > > Maybe it should be better to do a big step to 3.10.0... > > What are your feelings about that ? etch is frozen and will be released RSN, so there is no real point in doing 3.09.3, which cannot happen before the etch release anyway. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Meta-ocaml
On Fri, Mar 30, 2007 at 10:04:04PM +0200, Jérôme Marant wrote: > Hi, > > It looks like I'm still listed in the meta-ocaml package uploaders. > I just left the project so I guess the email address will bounce anytime soon. > > Thanks in advance for removing it. You left debian ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why and ergo
On Thu, Mar 22, 2007 at 07:17:14PM +0100, Samuel Mimram wrote: > Julien Cristau wrote: > > On Thu, Mar 22, 2007 at 18:00:33 +0100, Samuel Mimram wrote: > >> Unfortunately, I found out that ergo is under the CeCILL license which > >> is not DFSG-free if I remember well (am I wrong?). > > > > cecill is gpl-compatible. > > They claim so but it is not necessarily the case. In particular I think > that the choice of venue is not DFSG free: > > Article 13 - GOVERNING LAW AND JURISDICTION > > 13.1 The Agreement is governed by French law. The Parties agree to > endeavor to seek an amicable solution to any disagreements or disputes > that may arise during the performance of the Agreement. > > 13.2 Failing an amicable solution within two (2) months as from their > occurrence, and unless emergency proceedings are necessary, the > disagreements or disputes shall be referred to the Paris Courts having > jurisdiction, by the more diligent Party. > > Anyway, I'll ask on debian-legal. The Cecill licence has a specific GPL-compatibility clause, basically, you can use any of the cecill covered programs in a GPL fashion, so it is fine for debian main. This is also what i remember the consensus was when this came up on debian-legal, basically, you take the GPL-compatibility clause and ignore all the rest :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts about some new approx features ...
On Thu, Nov 16, 2006 at 10:40:42AM -0500, Eric Cooper wrote: > On Sat, Nov 11, 2006 at 10:09:38AM +0100, Sven Luther wrote: > > I just used approx to help me doing test installation with d-i. > > > > During this, there are 3 features, which i think may be useful : > > > > - ability to have approx take packages from more than one archive to put > > them in the same repository. > > > > This would allow to easily override the standard debian d-i .udebs, and > > make development of d-i much easier. Especially, since d-i doesn't support > > more than one .udeb repository right now. > > Can you explain the desired semantics of this? Would this be like a > search list (first one found), or union (most recent version among > all), or something else? Well, i was thinking of it acting the same way multiple sources work for apt. I am not sure how apt does this, but apt has a configuration file which can handle this. So i am not sure about the generic case. For the use i personally envision, that is to be able have an override for d-i .udeb packages, there would be various ways to handle this : 1) have some way to say that .../debian debian-installer/main ... comes from a different repository than ../debian etch. or whatever, i am not sure of the syntax, this way, the debian-installer .udebs can come from a (usually small) local mirror. 2) have a more complete solution. That is you could provide more than one apt source entry, and the highest version of the package would be used (what i believe to be what apt itself does) in case of duplicates. 3) have a way to tell that one list will take precedence over the other, independent of version of the packages. Typically, you would say : prefer my local partial archive over the generic full one. Well, this may be a bit confuse, but my main use will be simply to be able to provide some packages in a local archive, and use the main archive for d-i installation, plus the local archive for packages which override the full archive. > > - an option to automatically limit the approx archive to a given size, with > > an least-used or oldest removal algorithm. > > > > This would allow to not care about approx.gc, and would allow to let > > approx be running without having to think about it, and check that it will > > not eat the disk. > > > > Maybe something like the auto-clean feature of apt would be nice too ? It > > does keep only the latest version of all packages. Maybe something where > > we keep only packages accessible by the diverse Packages files from each > > repository ? > > That's exactly what gc_approx does -- removes everything not > reachable from the Packages/Sources files. Couldn't you just make it > run more frequently (default is cron.weekly, but you could make it > daily or hourly ...) Ah, nice. I didn't know gc_approx handled this in the cron table. But the idea is also to put a upper limit of the disk space approx will use, so approx will remove stuff if it reaches this. So, let's say approx has a limit of 100MB, for example, it files packages. Once it sees that the next package will break that limit (it knows about the size of packages), it launches gc_approx (maybe while it is retrieving the packages, not sure it this can be threaded, or gc_approx launched in another process or whatever). If this is not enough, then it erase non-duplicate packages, in a last-recently-used or oldest replacement algorythm. > > - Is there some way to control the syslog output, or to move the log into a > >/var/log/approx rotated log thingy ? Using approx intesively sure does > >file up the syslog quickly :) > > I can add a "quiet" mode that doesn't log anything unless there's some > error condition (or maybe that should be the default, with a "verbose" > mode instead?) It is nice to see the packages being downloaded, but in repeated install, they can pollute the normal syslog info, and you can miss stuff. So, the idea was to use a different log file than syslog (/var/log/approx ?). > Thanks for the suggestions. No problem, thanks for a great tool :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Thoughts about some new approx features ...
Hello, I just used approx to help me doing test installation with d-i. During this, there are 3 features, which i think may be useful : - ability to have approx take packages from more than one archive to put them in the same repository. This would allow to easily override the standard debian d-i .udebs, and make development of d-i much easier. Especially, since d-i doesn't support more than one .udeb repository right now. - an option to automatically limit the approx archive to a given size, with an least-used or oldest removal algorithm. This would allow to not care about approx.gc, and would allow to let approx be running without having to think about it, and check that it will not eat the disk. Maybe something like the auto-clean feature of apt would be nice too ? It does keep only the latest version of all packages. Maybe something where we keep only packages accessible by the diverse Packages files from each repository ? - Is there some way to control the syslog output, or to move the log into a /var/log/approx rotated log thingy ? Using approx intesively sure does file up the syslog quickly :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.09.2 + cdbs target release for etch
On Sat, Oct 28, 2006 at 04:24:12PM +0200, Stefano Zacchiroli wrote: > On Wed, Oct 25, 2006 at 09:15:58AM +0200, Sven Luther wrote: > > Why don't we upgrade to 3.09.3, and rebuild ? Have you speaken with > > the RMs about this ? It is just a point bug fix release, and by now it > > has been pretty tested upstream, so there should be no nasty > > surprises. > > I fear is too late in the release cycle to do that, besides it is not a Bah, we will not release for months anyway. > big deal to ship 3.09.2 instead of 3.09.3, the changes are really > minimal. Still, after the version I just uploaded enter testing we can > propose this to the RM asking for their advice. Ok. > My personal opinion is that it wont be _that_ easy given that some > packages currently present in unstable (at the very minimum some > packages of mine are not binNMU-safe, so sourceful uploads will be > needed). I do have the corresponding binNMU-safe versions on the svn > repository but they were never uploaded since I was waiting for the cdbs > class to be in unstable. Well, we have done it before, and without binNMU safe packages, but its upto you. > Ah, BTW, people now using the CDBS class can do that with a > build-dependency like ocaml-nox >= 3.09.2-7. Cool, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.09.2 + cdbs target release for etch
On Thu, Oct 26, 2006 at 08:36:15AM +0200, Stefano Zacchiroli wrote: > On Wed, Oct 25, 2006 at 08:44:38PM +, Sylvain Le Gall wrote: > > if you don't remove slashes, you get (after replacing OCAML_STDLIB_DIR), > > s/@OCamlStdlibDir@//usr/lib/ocaml/3.09.2//g > > which is not a good replacement. Using my subst, you get > > s/@OCamlStdlibDir@/\/usr\/lib\/ocaml\/3.09.2\//g > > which is better... and the \/ will become / in the target file. > > Ah ok, I understand now. You are perfectly right, I'll add your patch. Why not use % or any other char as the sed subst separator ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.09.2 + cdbs target release for etch
On Wed, Oct 25, 2006 at 08:25:07AM +0200, Stefano Zacchiroli wrote: > Hi all, > I chatted a bit with Samuel and Julien on IRC about the status of > dh_ocaml/md5sums. According to their opinions (which I consider > authoritative on the subject, since they did most part of the work on > the two tools recently) we wont have dh_ocaml/ocaml-md5sums ready for > etch. > > Given that the freeze for unstable will be anytime soon I wont dare > upload even 3.09.3 to unstable, no matter what the destiny of > dh_ocaml/ocaml-md5sums is. Why don't we upgrade to 3.09.3, and rebuild ? Have you speaken with the RMs about this ? It is just a point bug fix release, and by now it has been pretty tested upstream, so there should be no nasty surprises. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ara and anla at debian.net|org
On Sun, Oct 15, 2006 at 03:14:45PM +, Sylvain Le Gall wrote: > On 14-10-2006, George Danchev <[EMAIL PROTECTED]> wrote: > > Hello, > > > > As most of you know there is a web interface to ara [1] and > > edos-debcheck [2] > > (both packages are in Debian). These are great tools for package searching > > and problem diagnostics wrt QA of the packages, and I have received several > > messages from various people like "I am considering to submit a bug against > > packages.debian.org, asking them to replace the search of > > packages.debian.org > > by ara" ;-) > > > > This of course is great, but I have some questions which answers have > > probably been discussed during the meeting of a group of DDs with the > > EDOS-project people. > > > > 1) What version of ara runs at ara.edos-project.org ? I suspect it is some > > sort of enhanced version of svn.debian.org/svn/ara/branches/1.1.0 ? > > Currently > > 1.1.0 branch as found in svn does not compile, so I suspect there are some > > changes which has been applied to that tree. If there is anyone in close > > contact with EDOS people please ask them to send us the changes and > > probably > > to help merging bits from their 1.1.0 branch to the current ara's trunk. > > > > 2) Is there any enhancements to edos-debcheck to run at [2] ? > > > > Cannot answer both of this question. > > > 3) Should we ask for ara.debian.net (or .org) and anla.debian.net (or .org) > > ? > > I guess that running them in parallel to packages.debian.org would benefit > > much more users and reveal is a complete transition is needed and/or > > possible. This will also show what needs to be done in the future. I can > > imagine this could be a great help to QA and RM folks. > > > > As i told you in a private mail, i think it should be good thing. But i > don't know how to do it (for registering debian.net names). I also think > it is of great help for people (in general) ;-) Ask the web admin guys, there is debian-www or something such for that. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.09.3 debian plan
On Tue, Oct 10, 2006 at 09:02:48PM +, Sylvain Le Gall wrote: > Well, i am not in favor of this move before October 18th... Let me > explain : the freeze should be decided at this date (as far as i know). > So to my mind it is more important to fix any pending bugs on > every ocaml packages before trying to migrate all packages to 3.09.3... > If we do the migration, we will have a period of time where we cannot do > bug correction for packages in etch... > > On the other hand, i know that the freeze can shift in time, but let's > try not to be part of this shift ;-) > > Another, last solution is to do the migration in experimental... It is > also a good solution. This means that etch will ship with 3.09.2, right ? As for the freeze, it is most probable that etch will be delayed for a longer period of time, as the result of the GR vote will result, due to the hasty procedure of secretary, into a more messy situation that we are right now. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tarball free builds
On Thu, Oct 05, 2006 at 04:48:50PM +1000, skaller wrote: > On Thu, 2006-10-05 at 06:55 +0200, Sven Luther wrote: > > > Debian official source format is pristine upstream tarball > > + .diff.gz + dsc description file (or tarball + dsc file). > > > > So, i don't think you can replace that tarball with an svn tree, and > > furthermore you should really strip all the non-release information from > > said > > tarball (including the .svn stuff and so on). > > Why is that 'non-release' information? It is actually a supreme > pain removing precisely what I WANT people to get: a way to > upgrade their development tree. Because the packages are static tarball, used by build daemons to build debian binary packages, and not (not ever) intented to be installed on the user system for anything else than build packages of. The extra non-release information is just cruft which will bloat the archive. Users are not expected to use them to upgrade their devel tree in any way, please either use a distrib like gentoo if that is what you want, or have them build out of SVN, not use debian binary packages. > > But it is a bit unclear of what you intent to do. > > Simple: reduce the work of making a release to a > single svn command to tag the repository. Well, a proper do-release target in your makefile should easily enough achieve a proper and clean release tarball. Most everyone else does it, so it should not be all that complicated. > Reduce the maintenance of the release by refusing > to make any changes to it. If it doesn't work, > just get the next one (of course we will fix bugs .. > in the svn trunk). So, how is using this tag that different from using a plain pristine tarball generated from that tag ? The main point is though that we promised our users the source, accompanying the binaries more often than not, and there is no guarantee we have that your svn repo will stay on, or whatever. The tarballs mean we can guarantee to our users that the sources will not go away, they are archived at many places on the mirror network and at snapshot.debian.org too. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tarball free builds
On Thu, Oct 05, 2006 at 10:53:01AM +1000, skaller wrote: > hi, currently Debian typically requires 'tarballs' to make > source packages. > > This is a PITB because it requires some messy release concept, > keeping track of what needs to be tarred up, etc. > > I'm thinking of switching my project over so there's only > one way to build from source: directly from svn. > > This is partly because having switched from CVS to SVN > on Sourceforge, I've noticed that developers and non-developers > alike get the sources the same way from the same archive: > non-developers just can't commit. > > Instead of tarballs, just use a release tag. > > The problem is upgrading branches .. it's an untenable > violation of progress, requires messy merging, and other > stuff. If a tagged release is bugged .. too bad, try > the next one, we're only going to put fixes at the > head of the trunk. > > If you don't have svn .. you can't build the project > from source. Get real! You aren't a developer -- please > download a binary package! > > Is it practical to do this with Debian? With Ocaml-maint > the tarball is put in svn anyhow .. can we just copy > the svn image instead? Debian official source format is pristine upstream tarball + .diff.gz + dsc description file (or tarball + dsc file). So, i don't think you can replace that tarball with an svn tree, and furthermore you should really strip all the non-release information from said tarball (including the .svn stuff and so on). But it is a bit unclear of what you intent to do. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please upload approx from SVN
On Mon, Oct 02, 2006 at 08:58:26AM +0200, Ralf Treinen wrote: > On Sun, Oct 01, 2006 at 09:02:21PM +0200, Sven Luther wrote: > > On Sun, Oct 01, 2006 at 08:51:28PM +0200, Ralf Treinen wrote: > > > Hi Eric, > > > > > > On Fri, Sep 29, 2006 at 11:44:05AM -0400, Eric Cooper wrote: > > > > I've committed a new version of approx that should fix most of the > > > > outstanding bugs. I'd appreciate it if it could be uploaded soon so > > > > that it gets into etch. Thanks. > > > > > > I cannot find the package "approx" in the pkg-ocaml-maint svn > > > repository (in trunk/packages). Am I looking at the wrong place? > > > > Its probably in trunk/ > > Thanks, Sven. Indeed, it is in trunk/projects. I wasn't aware that some of > the native packages live outside of trunk/packages. Why is this so? Historical decision of back then, but i suppose it would be easier to move them to packages, really there is no benefit in keeping them separate, and there are drawbacks, as you showed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please upload approx from SVN
On Sun, Oct 01, 2006 at 08:51:28PM +0200, Ralf Treinen wrote: > Hi Eric, > > On Fri, Sep 29, 2006 at 11:44:05AM -0400, Eric Cooper wrote: > > I've committed a new version of approx that should fix most of the > > outstanding bugs. I'd appreciate it if it could be uploaded soon so > > that it gets into etch. Thanks. > > I cannot find the package "approx" in the pkg-ocaml-maint svn > repository (in trunk/packages). Am I looking at the wrong place? Its probably in trunk/ Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.09.3 released
On Sun, Sep 17, 2006 at 01:09:02PM +0200, Stefano Zacchiroli wrote: > In spite of having sent no announce to the OCaml mailing list, OCaml > 3.09.3 has been released 2 days ago, according to the website. The CVS > tags confirms that. > > IIRC currently the discussion with Vorlon we already did the needed > architecture regression tests with the rc1 in experimental (Julien, > could you please confirm that)? > > If all this is correct I think we are ready to upload ocaml 3.09.3 to > unstable ... Cool, but could you mail debian-release so they know about it ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDBS class for OCaml related packages
On Fri, Sep 15, 2006 at 04:04:09PM +0200, Stefano Zacchiroli wrote: > On Fri, Sep 15, 2006 at 04:59:24PM +0300, George Danchev wrote: > > ftpmasters are utterly unhappy with DEB_AUTO_UPDATE_DEBIAN_CONTROL quirks > > ;-) > > http://ftp-master.debian.org/REJECT-FAQ.html > > > See the comments after CDBS: " You have a cdbs package and for whatever > > reason > > turned on the play with my debian/control in a bad way option. See #311724 > > for a long text on that matter."... > > Please, ... we all know that, it has been discussed as lengthy as > possible. No need to start again. > > The conclusion is that it is absolutely forbidden to *automatically* > generate debian/control during build. No one has a problem with > generating debian/control before the package is uploaded to the archive. > > As a matter of fact the ocaml package already do that. As does the kernel packages, and the kernel .udeb packages, and probably a slew of others out there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ocaml on Arm
On Fri, Sep 15, 2006 at 08:33:29AM +1000, skaller wrote: > On Thu, 2006-09-14 at 23:48 +0200, Julien Cristau wrote: > > On Fri, Sep 15, 2006 at 07:09:20 +1000, skaller wrote: > > > > > On Thu, 2006-09-14 at 19:36 +0200, Julien Cristau wrote: > > > > On Fri, Sep 15, 2006 at 03:30:07 +1000, skaller wrote: > > > > > > > > > Current attempts to build Felix on arm processor by Debian > > > > > autobuilder indicate failures running Felix compiler which > > > > > is written in Ocaml: > > > > > > > > > see http://caml.inria.fr/mantis/view.php?id=3952 > > > > > > Thanks! I suppose I should add another bug report to them. > > > > > I don't know how another duplicate bug report would help, given that the > > main reason this is not getting fixed is that upstream doesn't have > > access to the hardware. > > Confirmation of a problem from multiple sources builds > confidence there really is a bug where people say there is, > and sometimes helps diagnosing it. I filed a note. > > Hmm .. isn't an 'arm' a small processor? I.e. a cheap > thing to own? Sure, your cellphone or wireless card probably has one, but there are various levels of cores (with or without mmu prbably), and owning one doesn't mean it is something useful for building ocaml one. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDBS class for OCaml related packages
On Thu, Sep 14, 2006 at 03:35:20PM +0200, Stefano Zacchiroli wrote: > On Thu, Sep 14, 2006 at 03:20:25PM +0200, Sven Luther wrote: > > > Comments are very welcome. > > What about the list of native arches ? > > I thought about that but I failed to put it down in a way useful to the > maintainer. > > Have you any concrete usage scenario in which it can be useful? It should be used to automatically set the set of Architectures of native arches in the control file, as well as used in addition or instead of the actual .opt detection we do now, altough this second feature is maybe not all that important. > Would it be enough to have a variable containing a space separated list Indeed this is what we provide : $ more /usr/lib/ocaml/3.09.2/native-archs alpha amd64 arm hurd-i386 i386 ia64 kfreebsd-i386 powerpc sparc > of the architectures? I initially thought has an OCAML_HAVE_* variable > set to 'yes' on native architectures, but it would be identical to the > OCAML_HAVE_OCAMLOPT I already provide ... Ah, ok, but the important point is the automatic updating of the Architecture: field in the control file. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDBS class for OCaml related packages
On Thu, Sep 14, 2006 at 10:38:53AM +0200, Stefano Zacchiroli wrote: > Hi all, > I drafted a CDBS class for OCaml related packages. It does not take > care of building anything (which is nearly impossible to do in a > standardized way, since every piece of ocaml software out there has a > different way of being built ...), but rather takes care of: > > 1) handling the .in stuff (substituting the @OCamlABI@ stamps in .in >files at the right moment during building, cleaning afterwards) > > 2) passing the arguments do dh_gencontrol so that F:OCamlABI fields in >debian/control are filled (this only if the debhelper class is used >as well) > > 3) providing some variables to be used by debian/rules writers >(e.g. OCAML_HAVE_OCAMLOPT, OCAML_STDLIB_DIR, ...) > > The class itself (coming in 2 files) is in trunk/tools/cdbs/ [1]. > The bug report asking for inclusion in CDBS is #387299. > Some samples of using the class are in > trunk/packages/gmetadom/branches/cdbs/ [3] and > trunk/packages/netclient/branches/cdbs/ [4]. > > Comments are very welcome. What about the list of native arches ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VCS info now available in the PTS
On Fri, Sep 08, 2006 at 08:49:42PM -0400, Eric Cooper wrote: > On Sat, Sep 09, 2006 at 12:13:58AM +0200, Sven Luther wrote: > > On Fri, Sep 08, 2006 at 04:52:38PM -0400, Eric Cooper wrote: > > > (view-svn is a shell script I hacked up and put in my PATH -- anything > > > that takes an SVN URL as a command-line argument would work) > > > > Would you care to share it ? > > It was just a trivial proof-of-concept, sorry: > #!/bin/sh > svn ls $1 | zenity --text-info > > (There are several real graphical SVN frontends according to apt-cache, > but none of the ones I tried could take a URL as a command-line argument.) Ah, but they cannot be viewed inside galeon, can they ? They will popup an external window, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VCS info now available in the PTS
On Fri, Sep 08, 2006 at 04:52:38PM -0400, Eric Cooper wrote: > On Fri, Sep 08, 2006 at 09:55:54PM +0200, Sven Luther wrote: > > /me wonders if galeon can be teached to know about svn, maybe > > calling svn ls on dirs, or something. > > You can use gconf to tell galeon about new protocols and their handlers: > gconftool -s /desktop/gnome/url-handlers/svn/enabled --type bool true > gconftool -s /desktop/gnome/url-handlers/svn/command --type string > "view-svn %s" > > (view-svn is a shell script I hacked up and put in my PATH -- anything > that takes an SVN URL as a command-line argument would work) Would you care to share it ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED]: [Caml-list] 3.09.3 release candidate 2]
- Forwarded message from Damien Doligez <[EMAIL PROTECTED]> - Message-Id: <[EMAIL PROTECTED]> From: Damien Doligez <[EMAIL PROTECTED]> Date: Fri, 8 Sep 2006 16:47:07 +0200 To: caml users <[EMAIL PROTECTED]> X-Mailer: Apple Mail (2.752.2) Subject: [Caml-list] 3.09.3 release candidate 2 Hello OCaml users, We have decided to make a second release candidate for 3.09.3. The only changes between rc1 and rc2 are camlp4-related: - camlp4: install pa_o_fast.o PR#3812 - camlp4: install more modules PR#3689 We would appreciate if camlp4 users (and particularly Hendrik) could test this version and report any problems found with it. Other users are still encouraged to try this one if they haven't tried 3.09.3+rc1. Like the previous one, this version is available from the CVS repository < http://camlcvs.inria.fr/cvsserver-eng.html >, but under the tag "ocaml3093rc2". Thanks for your cooperation, -- Damien ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs --- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VCS info now available in the PTS
On Fri, Sep 08, 2006 at 07:57:55PM +0200, Stefano Zacchiroli wrote: > On Mon, Sep 04, 2006 at 12:53:41PM +0200, Stefano Zacchiroli wrote: > > recently I started adding to my debian/control the field X-Vcs-Svn, > > Raphael Hertzog just informed me that he applied a patch of mine to the > PTS. As a result, the information conveyed by our beloved X-Vcs-Svn > field is now browsable from the PTS pages, when available. > > For an example go to: > > http://packages.qa.debian.org/p/pcre-ocaml.html > > and look for the "VCS" field in the "General Information" box at the top > left of the page. Would be nice if the link pointed to the web interface to svn or something. clicking on it, i get a svn protocol not identified thingy. /me wonders if galeon can be teached to know about svn, maybe calling svn ls on dirs, or something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Could somebody check my first ocaml package ?
On Fri, Sep 08, 2006 at 01:37:21PM +0900, Charles Plessy wrote: > Dear ocaml developpers, > > I am bringing scientific software for molecular biology into Debian, and > one of my package contains an ocaml program. > > I have read the ocaml policy, and tried to do everything correctly, but > I would appreciate some proofreading before I send the package to my > sponsor. > > In particular, lintian and linda complain about the binary to be > unstripped, but if I understand correctly, this is necessary. Shall I > override the errors? > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/s/sigma-align > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/s/sigma-align/sigma-align_1.0-1.dsc > > It is sort of trivial (the source is one single .ml file), so I think > that the proofreading can be very quick. > > Have a nice day > > (PS: I am not subscribed to the list) It would be best if you maintained it inside the ocaml svn repo, like all other ocaml related packages. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: [Caml-list] 3.09.3 release candidate 1]
On Wed, Aug 30, 2006 at 01:31:05PM +0200, Samuel Mimram wrote: > Get prepared for a new full rebuild! BTW, there will be ocaml 3.10.0 soon, or so Xavier says, not sure how soon soon is. What is the plan with regard 3.09.3 vs 3.10.0 for etch ? Anyone had a thought of it already ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding X-Vcs-Svn source field to ocaml related packages
On Tue, Sep 05, 2006 at 10:08:38PM +0200, Samuel Mimram wrote: > Sven Luther wrote: > > On Tue, Sep 05, 2006 at 09:26:04PM +0200, Stefano Zacchiroli wrote: > >> On Mon, Sep 04, 2006 at 12:53:41PM +0200, Stefano Zacchiroli wrote: > >>> If noone object to this change I will commit it in the next days. > >> Done. > >> > >> Please note that I committed changes to debian/control, *not* to > >> debian/control.in, where available. Packages having debian/control.in > > > > Control.in are nice, it is cdbs which is broken. > > What's the use of control.in? Good dependencies are already ensured by > dependencies on ocaml-nox-VERSION. As discussed on irc, this is needed for the ocaml native arch trick, and i believe also the implementation of native packages side of it. Not totally sure about this last one though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding X-Vcs-Svn source field to ocaml related packages
On Tue, Sep 05, 2006 at 10:55:33PM +0200, Stefano Zacchiroli wrote: > On Tue, Sep 05, 2006 at 10:23:38PM +0200, Sven Luther wrote: > > No, you cannot change build-depends that way, and thus the control.in are > > needed to easily generate the build-depends before the upload, altough they > > are should never be called interactively, which cdbs does. > > [ We cleared this on IRC, summary FYI ... ] > > There is no real need to bump the build-deps. A bumped build dep would > be a "lie" if a package builds with a previous ocaml version. A > non-bumped one, in the worst case, would mean the autobuilders build a > package with an old ocaml version. Not a big deal: the package would be > RC, but can be rescheduled requiring a binNMU. We would need some check to make sure we don't miss some of those on some slower and less used arches, but i guess the testing migration scripts will catch those, when the older ocaml is removed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding X-Vcs-Svn source field to ocaml related packages
On Tue, Sep 05, 2006 at 10:16:44PM +0200, Stefano Zacchiroli wrote: > On Tue, Sep 05, 2006 at 10:01:31PM +0200, Sven Luther wrote: > > Control.in are nice, it is cdbs which is broken. > > My comment had nothing to do with cdbs. > > Al we need to dynamically fill in debian/control can be done with > substitution variables. We have no need of debian/control.in files. No, you cannot change build-depends that way, and thus the control.in are needed to easily generate the build-depends before the upload, altough they are should never be called interactively, which cdbs does. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding X-Vcs-Svn source field to ocaml related packages
On Tue, Sep 05, 2006 at 09:26:04PM +0200, Stefano Zacchiroli wrote: > On Mon, Sep 04, 2006 at 12:53:41PM +0200, Stefano Zacchiroli wrote: > > If noone object to this change I will commit it in the next days. > > Done. > > Please note that I committed changes to debian/control, *not* to > debian/control.in, where available. Packages having debian/control.in Control.in are nice, it is cdbs which is broken. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding X-Vcs-Svn source field to ocaml related packages
On Mon, Sep 04, 2006 at 05:18:40PM +0200, Stefano Zacchiroli wrote: > On Mon, Sep 04, 2006 at 05:11:21PM +0200, Sven Luther wrote: > > > Yes ... but why? > > No idea, how is this field used, and by whom ? And why did the Python guys > > Ah ok :-) > > > add a python version in this field. I suppose it is for something python > > versioning/abi-name related, which is similar to what we do. > > > > The question of interest is to know what the dpkg/apt/whatever tools do > > about > > this. > > The fields named XS-whatever flows through (dak, whatever, ...) and > arrive to the Sources files without the heading "XS-". Similarly the > fields named XB-whatever end up in the Packages file. > > I do not know more than this. > > The python guys use that to decide at postinst time which binary version > of a python library precompile. We do not have such a need, our binary > packages already contain the compiled versions. Ok. That said, i find the SVN field name a bit obscure, why was there not a more straingthforward one (X-SVN or something such) chosen ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding X-Vcs-Svn source field to ocaml related packages
On Mon, Sep 04, 2006 at 05:02:43PM +0200, Stefano Zacchiroli wrote: > On Mon, Sep 04, 2006 at 02:54:16PM +0200, Sven Luther wrote: > > So, we could add the ocaml abi number in XS-Ocaml-ABI or something such ? > > Yes ... but why? No idea, how is this field used, and by whom ? And why did the Python guys add a python version in this field. I suppose it is for something python versioning/abi-name related, which is similar to what we do. The question of interest is to know what the dpkg/apt/whatever tools do about this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding X-Vcs-Svn source field to ocaml related packages
On Mon, Sep 04, 2006 at 02:47:30PM +0200, Stefano Zacchiroli wrote: > On Mon, Sep 04, 2006 at 02:17:56PM +0200, Samuel Mimram wrote: > > I find all this very nice but I was wondering: in what measure all this > > is standardized? Is there a (unofficial) list of commonly used XS-X-... > > fields in debian/control files? Else we might end up with lots of > > AFAIK there is not such list. > > I know of only two uses of XS-X fields: > - XS-Python-Version (or something like that), mandated by the new python > policy > - XS-X-Vcs-Svn, discussed on debian-devel some weeks ago > > There is no standardization for headers related to the vcs used by a > package, but there is currently no drift either. The only packages I > found with such info are Dato's and I inherited from it. So, we could add the ocaml abi number in XS-Ocaml-ABI or something such ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: [Caml-list] 3.09.3 release candidate 1]
On Thu, Aug 31, 2006 at 08:28:09AM +0200, Stefano Zacchiroli wrote: > On Wed, Aug 30, 2006 at 05:21:23PM -0700, Steve Langasek wrote: > > 2) please try to check whether this new upstream version includes any > > regressions in the set of architectures supported for native compiling. The > > latter has happened before in the past, and it would be unpleasant to have > > to deal with such a transition at this point in the release cycle. > > Thanks for the feedback. > > Just to move in advance: what do you suggest to do in case (2) is > actually the case? Maybe going to a more generic usage of arch: all bytecode, like the spamoracle case. This would not work for C bindings, but in all the other case, it would simply mean that if a native arch dissapears, a bunch of binary packages would not build on said arches, but that would be just fine, since the arch:all version would be in the archive, and seamlessly replace it. We would need to purge older versions of the packages out of the archive though, and the real problem are those libraries which hold C bindings. We would need to more strongly list them, and run a rebuild of those on those arches, but maybe since it is targeted at those arches, it would be possible to do a manual run or something. Ideally, if buildd's where able to build from the archive *and* already built packages, and handle the (build-)dependency tree, including those package already built but not uploaded or those scheduled for build, it would make this issues much easier. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: [Caml-list] 3.09.3 release candidate 1]
On Wed, Aug 30, 2006 at 01:31:05PM +0200, Samuel Mimram wrote: > Get prepared for a new full rebuild! Can you post this to debian-release, i am banned from it, and i think it is impportant they know about this new development. I will inform Steve Langasek on irc. Friendly, Sven Luther > Cheers, > > Samuel. > > > Original Message > Subject: [Caml-list] 3.09.3 release candidate 1 > Date: Wed, 30 Aug 2006 13:21:37 +0200 > From: Damien Doligez <[EMAIL PROTECTED]> > To: caml users <[EMAIL PROTECTED]> > > Hello, > > We have a release candidate for 3.09.3. It is available from the CVS > repository < http://camlcvs.inria.fr/cvsserver-eng.html > under the > tag "ocaml3093rc1". > > We would appreciate the help of any user who wants to test this > version and report any problem encountered (as usual, through the > BTS: < http://caml.inria.fr/mantis/main_page.php >). > > It will become a full release in one or two weeks unless some serious > bug is reported in the meantime. > > -- the OCaml team. > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > --- > Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pkg like shlibs
On Mon, Aug 28, 2006 at 08:26:46AM +1000, skaller wrote: > On Sun, 2006-08-27 at 23:26 +0200, Sven Luther wrote: > > On Mon, Aug 28, 2006 at 07:03:40AM +1000, skaller wrote: > > > On Sun, 2006-08-27 at 22:29 +0200, Sven Luther wrote: > > > > > > > > Yup, I have one, although I can't figure out how to install a .deb > > > > > and its dependencies at the moment. Is there a tool for that? > > > > > > > > apt-get ? > > > > > > Apt requires a list of archives? One .deb isn't an archive :) > > > > Well, sure. dpkg -i blah.deb then. > > Yeah but that doesn't load the dependencies. > > I griped before on the mentors mailing list about the woefully > complex non-orthogonal dysfuncational collection of tools > Debian uses .. but understandably did not get a favourable > response .. :) Ah, i see what you mean. Well, the easiest way is to create a repository with the single package in it, and then use apt-get. also, try installing the package, maybe with --force-depends, and then do an apt-get install -f or something such. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pkg like shlibs
On Mon, Aug 28, 2006 at 07:03:40AM +1000, skaller wrote: > On Sun, 2006-08-27 at 22:29 +0200, Sven Luther wrote: > > > > Yup, I have one, although I can't figure out how to install a .deb > > > and its dependencies at the moment. Is there a tool for that? > > > > apt-get ? > > Apt requires a list of archives? One .deb isn't an archive :) Well, sure. dpkg -i blah.deb then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pkg like shlibs
On Mon, Aug 28, 2006 at 04:41:13AM +1000, skaller wrote: > On Sun, 2006-08-27 at 19:52 +0200, Sven Luther wrote: > > On Sun, Aug 27, 2006 at 07:49:42PM +1000, skaller wrote: > > > > I can cope with that temporarily -- just tell people to > > > > > > cp -R /usr/lib/felix/felix-1.1.2 /usr/local/felix/ > > > > > > or perhaps copy to ~/felix as they see fit -- if they want to save > > > > Bah, just go the full way, and have binaries being version dependent, like > > gcc > > does. > > But this: > > " 2) we decided to keep only a single ocaml non versioned package, >in order to avoid issues with NEW and lag due to the >ftp-masters overload." > > seemed like good advice. Notice that since that time, NEW handling improved tremendously. Also, ocaml is a set of tens of packages, while i believe that felix can right now at least be fully self-contained, no ? > > > the old version. I won't be installing my own package .. I don't > > > want any installed version because it will interfere with testing > > > the development version. Also why I don't install Ocaml via > > > > Bah, just install in a separate changeroot. > > Yup, I have one, although I can't figure out how to install a .deb > and its dependencies at the moment. Is there a tool for that? apt-get ? Just go into the chroot, and use the apt-get tool normally, you maybe need to reset your /etc/resolv.conf and apt sources, but apart from that, it is a fully functioning environment. Not sure, but you could maybe even try to run a fully fledged X inside it :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pkg like shlibs
On Mon, Aug 28, 2006 at 02:03:16AM +1000, skaller wrote: > On Sun, 2006-08-27 at 16:56 +0200, Samuel Mimram wrote: > > skaller wrote: > > > On Sun, 2006-08-27 at 10:13 +0200, Sven Luther wrote: > > > > > >> We already moved some this way with ocaml, who installs in > > >> /usr/lib/ocaml/, but didn't go the full way. > > > > > > Ok, can I do this too? I would install in: > > > > > > /usr/lib/felix/felix-1.1.2 > > > > Why not /usr/lib/felix/1.1.2? (just a matter of taste) > > No particular reason. I followed the model for Ocaml Sven ocaml is /usr/lib/ocaml/3.08-3 or something such. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
