Re: Bug#797473: frama-c: New upstream version
Hello, Le 30/08/2015 23:24, Kurt Roeckx a écrit : It seems there is a new upstream version. Could you upload it? The Sodium version was published in 2nd of February 2015, about 7 months ago. For end-user tools when you always need latest version, you'd rather use another mean that Debian packages: i.e. another distribution (e.g. Fedora where as far as I know they are up-to-date) or through tool specific channel on your Debian (e.g. OCaml's opam[1] package management system, where Frama-C is available in latest version). I'm using both of them. For Debian developer: this is not an "angry user rant" but for me a *structural* limitation of modern Debian unable to provide needs of a significant part of users[2]. Of course, Debian is fine when you need a very stable platform where software are not evolving or very slowly (i.e. server). Even in this case, backports are often needed. Best regards, david [1] But I don't know if opam 1.2.0 available in Debian stable works well with latest opam repositories. opam is at version 1.2.2. [2] By the way, is there a bug open for it? Is it worth it?
Re: Bug#714124: frama-c: nitrogen Frama-c is two versions older than fluorine
Hello, 2013/6/26 Logan Rosen lo...@ubuntu.com: Please upgrade frama-c's packaging to the latest upstream version. Zack, for once, I'm not the only one. ;-) Best regards, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC3Lx=zsw77i2qkwbthbx9tu-5svmqwh8cuzk1wy0xnbkhv...@mail.gmail.com
Re: Bug#663754: ITP: hol-light -- HOL Light theorem prover
Hello, Disclaimer: I'm not a Debian developer, just a user. 2012/3/22 Hendrik Tews t...@os.inf.tu-dresden.de: Currently I do 4 of the about 110 tests. Each of them takes about 90 seconds on my Core Duo @ 2.80GHz. How much time should I spend on testing during package build? As far as I have understood, those tests are testing internal HOL logic. If you haven't modified any line of the original code, I don't see why those tests would fail (under assumption: all the relevant modules have correctly been installed). The only things that a packaging can change is the interface with the environment of the package. So my rationale would be to keep at least one test to be sure that HOL Light can be run (ideally one function in each module of the original code), and then keep as many tests as needed to test the interface with the outside world (e.g. call to an external prover). Best regards, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC3Lx=bzhifu4cmv0xfuwjxy1v4yfl8ur-71owla1jzzwi6...@mail.gmail.com
Bug#663180: Provides no zero value
Hello, 2012/3/11 Goswin von Brederlow goswin-...@web.de: An option type has the drawback that you have to extract it every time you use it. That means more typing, less readable code and slower code. That might seem minor but it does add up. Yes, I know. That's why I suggested you use it in your *initialization* code. Best regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC3Lx=yjfmgvvv+akgy0bztbyjzjmmw7fqndhupn88qzpwr...@mail.gmail.com
Bug#663180: Provides no zero value
Hello, 2012/3/10 Goswin von Brederlow goswin-...@web.de: I can't because the Sha1.t is abstract. I think what David means is that you can just define let my_initializer = Sha1.string somewhere at the beginning of your code. Yes. let () = Printf.printf %s\n (Sha1.to_hex (Sha1.string )) da39a3ee5e6b4b0d3255bfef95601890afd80709 This would certainly work as an initializer but would not be obviously invalid. [...] This on the other hand is easy to spot in output or when stored in files and unlikely to occur naturaly. I don't buy your argument (only a human can spot the value) but I understand your point of view. Another option would be to use Some h | None in your initialization code and convert it to an immutable value at the end of the initialization. Best regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC3Lx=bovJpOJTub2RANZKTse3qBPB4gVscZDidWmRg=y53...@mail.gmail.com
Bug#663180: Provides no zero value
Hello, 2012/3/9 Goswin von Brederlow goswin-...@web.de: I found myself in a situation where I needed to fill in a dummy Sha1.t into a record to initialize an array. I didn't want to use an Sha1.t option because the value is only every invalid during initialization and an option type would mean extracting from Some x at every other place. The attached patch adds a Sha*.zero value that can be used for this purpose. Why don't you define this Sha1.zero value in your code and use it there? This patch seems to me very specific to your code and of dubious use in a library. Best regards, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC3Lx=awmsrtqc3sqjtas5ux8yghvjyqklekbn_3tutbymc...@mail.gmail.com
Re: Debian policy regarding debian/ upstream directory
Hello Stéphane, 2012/1/30 Stéphane Glondu glo...@debian.org: Not exactly. What I meant is that in Debian, stuff might be changed in debian/ independently of upstream. For example, to follow changes in policy, package renaming, transitions, etc. The upstream Debian packaging then becomes osbolete, and it seems wrong to me to make a new upstream release just to keep up with Debian-specific changes. Well, it depends on ability of upstream to make minor releases. But I understand that could be an issue and that separated debian/ makes package management easier for Debian. Thank you for the clarifications, Best regards, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC3Lx=zchff2ccqqrsu_xzg8lzdi4eabiknrgclp8vs8gui...@mail.gmail.com
Debian policy regarding debian/ upstream directory
Hello Stéphane, 2012/1/26 Stéphane Glondu glo...@debian.org: Moreover, I saw that the debian/ repository is also part of the upstream tarball. Keep in mind that it is completely ignored by Debian tools with the 3.0 (quilt) format (only the one from .debian.tar.gz is taken into account), which is a good thing. The rationale is that the upstream Debian packaging is (conceptually) not the same as the one officially in Debian (or in another dpkg-based distribution), each might evolve differently and comparing both might not even make sense. Is this because, for example, both Ubuntu and Debian are using this debian/ repository? As a programmer, it seems to me counter-productive to keep package relative information in several places instead of putting them in only on place, in the upstream tarball. In upstream, several packagers (Fedora, Debian, ...) can copy best practices *for this package*, instead of reinventing the wheel (I'm thinking at init script for example). Best regards, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC3Lx=asaUoWS9zbmNTQ6RsXwwsMd=yyquzsancqv1itsp5...@mail.gmail.com
Re: 2 coq emacs modes
Hello, 2012/1/13 Hendrik Tews t...@os.inf.tu-dresden.de: 1) leave the situation as is People not using Proof General will hopefully not install Proof General and therefore don't see the problem. 2) make a separate package for the emacs mode in Coq This way users are forced to make a decision. However, it is questionable if this is worth the effort, because nobody seems to use the coq-mode distributed with coq. coq-mode from Coq was completely broken in squeeze (#605024) and only people using Proof General noticed it, i.e., people either install coq allone and do not use emacs _or_ they install coq and Proof General. 3) delete coq-mode from package coq 4) ask a debconf question when Proof General is installed Another proposal: 5) Still install coq-mode but request a user action (i.e. putting something in .emacs) to activate it. Document it in README.Debian. Best regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC3Lx=YTW++y1S0r=e-e1qq+zme__m90r35jhtnuk+plgb9...@mail.gmail.com
Re: 2 coq emacs modes
Hello, 2012/1/13 Hendrik Tews t...@os.inf.tu-dresden.de: I would not like to see 5) for the coq-mode of Proof General. For the coq-mode of coq 5) would be fine with me, because IMHO nobody is using it, at least not the one distributed with Debian. Yes, yhis was the intent of my proposal: explicit activation for coq-mode of Coq, implicit activation for ProofGeneral's coq-mode. Best regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC3Lx=Y3X_RqE3=51eq2oveznatm-_f4z+o+rrort05laft...@mail.gmail.com
Re: Transition to OCaml 3.12.0...
Hello Mehdi, 2011/3/10 Mehdi Dogguy me...@debian.org: You should not be able to upgrade packages if the dependencies are broken :) What I fear most is an upgrade that would remove some essential OCaml packages on my Debian sid development machine. I know the breakage would be only over a limited period, but I should take into account Murphy's law: it will be at the worst time for me. :-) Best regards, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikfnaqtdq8zqlrywo5vjlvkgqku2raxveobw...@mail.gmail.com
Re: Transition to OCaml 3.12.0...
Hello Stéphane, 2011/3/10 Stéphane Glondu glo...@debian.org: After #613848 is done. Could we have a message on this list when the transition is started, so has to avoid upgrading or installing packages during it? Thank you. Best regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi¿xjCnv_TgETc-jG3wW=jabsukur+mveph...@mail.gmail.com
Re: ocamlopt failed on ASM compilation
Hello, 2011/3/9 Sylvestre Ledru sylves...@debian.org: /tmp/camlasme79e83.s:31578: Error: .size expression does not evaluate to a constant This is related to following bug: http://lists.debian.org/debian-ocaml-maint/2011/03/msg00046.html In short, OCaml compiler breaks on latest binutils. The fix is in the pipeline (and maybe already available). Sincerely yours, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinymoq5evtumst1vkrwbwr4-nvjb-fbwx83q...@mail.gmail.com
Update of monitoring of OCaml packages on Ubuntu
Hello, I'm rather late but I have updated my monitoring scripts to now watch Ubuntu's Maverick packages. All the made page are accessible from Debian Wiki (section More stuff - resources) http://wiki.debian.org/Teams/OCamlTaskForce The package dependencies are all green. I assume that this is due to the recent dependency work in Debian. Thanks! http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ocaml_transition_monitor.html Best regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=da1ymhvr2qkm_qz6drq9oyyx8cqexntdwb...@mail.gmail.com
Re: overhaul of the debian ocaml policy
Hello, I don't want to start yet another flameware, please take this answer with a grain of salt. But I could not refrain myself. ;-) 2010/8/23 Ralf Treinen trei...@free.fr: PS: I just looked up the bug report, which reveals what distro the bug reporter is using. Ubuntu. He rather should complain to his distro when they are just copying our stuff and then, on top of it, get it wrong (as I deduce from the fact that he could not rebuild his package). There are no OCaml developers in Ubuntu. The bug report would come back to Debian. And Ubuntu people are hardly ever patching Debian OCaml packages (https://bentobako.org/ubuntu-ocaml-status/raw/ubuntu-patches.html). rantMaybe some Debian developers should understand that a significant part of Debian OCaml work users are on Ubuntu. Rather than a competitor, Ubuntu offers a wider exposition to Debian Developers work./rant Sincerely yours, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinh0jj5cchfz82hwsymjuxnsx2y+aga2wjz+...@mail.gmail.com
Bug#574887: ocsigen: Put XHTML.M in its own binary package
Hello Mehdi, 2010/3/21 Mehdi Dogguy me...@debian.org: Would it be possible to split it in a new binary package provinding only XHTML.M to ease its installation and use? Is this really necessary? What is a lot of dependencies? Are there a lot of people that would like to use XHTML.M but not ocsigen and *with* disk space constraints? While Debian dependency system is nice, more packages mean a more complex system that need to be maintained. Simplicity is virtue in engineering and computer science. Best regards, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3d13dcfc1003220129n2d02ca20l5ac621c7ccdee...@mail.gmail.com
Bug#574887: ocsigen: Put XHTML.M in its own binary package
Hello Mehdi, Sorry if my initial message was a bit harsh, it was not my intent. 2010/3/22 Mehdi Dogguy me...@debian.org: What is a lot of dependencies? Did you try to install it and see what it brings on disk? No. If not, please read the following few lines and tell me if installing 192MB is worth it when I need only 100KB of them. From Stéphane's reply, it reduces the installation to 114 MB instead of 211MB. A real improvement but not an impressive one. Mainly, because I think that keeping a system as small as possible and only with the required stuff (especially on a server) is a sane approach. I agree. Adding one binary package (or even 10) don't make the dependency system complicated. It may complicate the packaging is a bit but I think that these changes will be integrated upstream (maybe partially) to ease such operations. Please note that package splitting in Debian is done on request basis (when justified… which is the case here) and not on the number of people asking for it. Please also note that I've set the severity to minor. I agree it is not probably one of the most complicated binary packages in Debian, but it still increases the number of packages to take care of, e.g. when the OCaml compiler is upgraded. I'm not a Debian Developer and I do appreciate a lot the hard work put into packaging by Debian developers, especially for OCaml. I just wanted to point out the potential issue of having a lot of packages, being complicated or not. I sometimes have the feeling that too many packages are created, some of them not really useful (e.g. -dev split). We all want a high quality system, well maintained and useful to use. Most of the time, I install a generic package (like ocaml) with all its dependencies. There are a ot of free space on hard disks nowadays. Of course, I do not claim that my use is the use of others. ;-) *We* will maintain it and keep it clean. If Stéphane needs some help to maintain this packaging, I'm ready to help, as I always did in the OCaml Team. I am well aware of this and, once again, I do appreciate a lot the effort and the result. Best regards, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3d13dcfc1003220637t4f836767k8ce98955d78a...@mail.gmail.com
Re: Objective Caml 3.11.2 in Debian
Hello Stéphane, 2010/1/20 Stéphane Glondu st...@glondu.net: I've recompiled (on amd64) all relevant packages with the release candidate (announced last Dec 29), and all problems have been sorted out. As far as I am concerned, I see no objections in starting the transition. Great! I'm asking those questions of course because I'm looking at OCaml in Ubuntu. I guess the Ubuntu transition can be made in parallel. Yep. Actually, importing all packages at once when everything in Debian reaches testing looks like a bad idea. Some coordination with Ubuntu maintainers (David, could you look for one willing to take the job?) will be needed so that everything goes smoothly. Yes. I fear I'll have to take that job once again. :-) But only for LTS Lucid! ;-) I'll check with Ubuntu people if they agree and to find some help. BTW, I've updated my transition script for Lucid and they are running daily. I only need to make them watch 3.11.2. http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ocaml_transition_monitor.html http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ports_transition_monitor.html Regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Objective Caml 3.11.2 in Debian
Hello, Immediate questions following Damien's announcement: * Can I assume that you are going to release new Debian package shortly? * How long the package need to reach testing once uploaded, 10 days? I'm asking those questions of course because I'm looking at OCaml in Ubuntu. Best regards, d. -- Forwarded message -- From: Damien Doligez damien.doli...@inria.fr Date: 2010/1/20 Subject: [Caml-list] ANN: Objective Caml 3.11.2 released. To: caml users caml-l...@inria.fr, caml announce caml-annou...@inria.fr Dear OCaml users, It is our pleasure to celebrate the birthday of Andre-Marie Ampere by announcing the release of OCaml version 3.11.2. This is mainly a bug-fix release, see the list of changes below. It is available here: http://caml.inria.fr/download.en.html . It is source-only for the moment, but the binary versions will be made available soon. Note that there are still known problems under Windows with the experimental procedure of building the system with ocamlbuild, so you should build with make for the moment. Happy hacking, -- the OCaml team. Objective Caml 3.11.2: -- Bug fixes: - PR#4151: better documentation for min and max w.r.t. NaN - PR#4421: ocamlbuild uses wrong compiler for C files - PR#4710, PR#4720: ocamlbuild does not use properly configuration information - PR#4750: under some Windows installations, high start-up times for Unix lib - PR#4777: problem with scanf and CRLF - PR#4783: ocamlmklib problem under Windows - PR#4810: BSD problem with socket addresses, e.g. in Unix.getnameinfo - PR#4813: issue with parsing of float literals by the GNU assembler - PR#4816: problem with modules and private types - PR#4818: missed opportunity for type-based optimization of bigarray accesses - PR#4821: check for duplicate method names in classes - PR#4823: build problem on Mac OS X - PR#4836: spurious errors raised by Unix.single_write under Windows - PR#4841, PR#4860, PR#4930: problem with ocamlopt -output-obj under Mac OS X - PR#4847: C compiler error with ocamlc -output-obj under Win64 - PR#4856: ocamlbuild uses ocamlrun to execute a native plugin - PR#4867, PR#4760: ocamlopt -shared fails on Mac OS X 64bit - PR#4873: ocamlbuild ignores thread tag when building a custom toplevel - PR#4890: ocamlbuild tries to use native plugin on bytecode-only arch - PR#4896: ocamlbuild should always pass -I to tools for external libraries - PR#4900: small bug triggering automatic compaction even if max_overhead = 1M - PR#4902: bug in %.0F printf format - PR#4910: problem with format concatenation - PR#4922: ocamlbuild recompiles too many files - PR#4923: missing \xff for scanf %S - PR#4933: functors not handling private types correctly - PR#4940: problem with end-of-line in DOS text mode, tentative fix - PR#4953: problem compiling bytecode interpreter on ARM in Thumb mode. - PR#4955: compiler crash when typing recursive type expression with constraint - Module Printf: the simple conversion %F (without width indication) was not treated properly. - Makefile: problem with cygwin, flexdll, and symbolic links - Various build problems with ocamlbuild under Windows with msvc Feature wishes: - PR#9: (tentative implementation) make ocamldebug use #linenum annotations - PR#123, PR#4477: custom exception printers - PR#3456: Obj.double_field and Obj.set_double_field functions - PR#4003: destination directory can be given to Filename.[open_]temp_file - PR#4647: Buffer.blit function - PR#4685: access to Filename.dir_sep - PR#4703: support for debugging embedded applications - PR#4723: clear_rules function to empty the set of ocamlbuild rules - PR#4921: configure option to help cross-compilers ___ 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 debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#564334: cameleon: Config files not preserved when updating.
Hello, 2010/1/19 Guillaume Yziquel guillaume.yziq...@citycable.ch: Mehdi Dogguy a écrit : IMHO, It's not even an issue. We changed the used library and its configuration directory changed as well since it matches the library's name. You upgrade a package. You lose your configuration. This is not an issue. ? I would be inclined to agree with Guillaume and say in such case that this is an error not to keep configuration from one version to the other of the same software. On this other side, as an application developer, doing and maintaining such upgrade path can be complicated and should be balanced with the impact of re-doing the configuration for the user. I don't know Cameleon but I assume re-configuring the application is not such a big task. Moreover, in this particular case, the non-upgrade issue should appear only once. So closing this bug seems to me quite reasonable. Maybe adding a short note in README.Debian could be useful. Best regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
How to verify coherency of Coq and OCaml packages?
Hello, I just realized that the coq-doc package is stuck to 8.0pl1.0-1 since Dapper on Ubuntu (and is thus cannot be installed in parallel with coq :-( ): http://packages.ubuntu.com/search?keywords=coq Is there a script somewhere that would help me to find such issues for Coq and OCaml, like Stephane Glondu's ocaml_transition program? Best regards, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to verify coherency of Coq and OCaml packages?
Hello Mehdi, 2010/1/15 Mehdi Dogguy me...@dogguy.org: Maybe a sync request is needed to get the latest coq-doc package? I'll contact Ubuntu developers and check with them. Thank you Mehdi and Stéphane for the feedback. Regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to verify coherency of Coq and OCaml packages?
Hello, 2010/1/15 David MENTRE dmen...@linux-france.org: I'll contact Ubuntu developers and check with them. Thank you Mehdi and Stéphane for the feedback. Ubuntu developer response (Benjamin Drung): It's not synchronised with Debian, because we sync automatically from Debian testing (and testing has currently only the old version). You can solve this issue by requesting a sync from Debian unstable (using the requestsync tool), which I have done for you now: https://launchpad.net/bugs/508116 It is not clear to me that Benjamin's response explains why coq-doc has not been updated in Ubuntu since Dapper. Anyway, the issue will be solved shortly. Regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to verify coherency of Coq and OCaml packages?
2010/1/15 David MENTRE dmen...@linux-france.org: It is not clear to me that Benjamin's response explains why coq-doc has not been updated in Ubuntu since Dapper. Anyway, the issue will be solved shortly. The explanation of Benjamin Drung: Looking at https://launchpad.net/ubuntu/+source/coq-doc , the package was synced in hardy (version 8.1-3). The problem was, that this package failed to build from source (FTBFS). Therefore there were no new binaries. Regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Update of scripts comparing Ubuntu Lucid and Debian testing
Hello, 2010/1/13 David MENTRE dmen...@linux-france.org: Are there a lot of differents between Debian's ocaml 3.11.1-4 and 3.11.1-5? Would importing 3.11.1-5 in Lucid trigger an OCaml transition? To partially answer my own question, after looking at http://git.debian.org/?p=pkg-ocaml-maint/packages/ocaml.git;a=shortlog;h=refs/tags/debian/3.11.1-5 , it seems that only following changes have be done. I have drawn the conclusion that those changes are not needed for Ubuntu Lucid (Lucid is using Tcl/Tk 8.4). 2009-12-15 Stephane Glondu Prepare upload to unstable debian/3.11.1-5 commit | commitdiff | tree | snapshot 2009-12-14 Stephane Glondu Use Tcl/Tk 8.5 commit | commitdiff | tree | snapshot 2009-12-14 Stephane Glondu Update control.in commit | commitdiff | tree | snapshot 2009-12-14 Stephane Glondu NOT RELEASED YET commit | commitdiff | tree | snapshot 2009-11-10 Mehdi Dogguy Don't forget to close old bugreports when 3.12 will... Regards, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Update of scripts comparing Ubuntu Lucid and Debian testing
Hello, For what it's worth, I have updated my scripts to compare Ubuntu Lucid with Debian testing, as Lucid is based on testing. http://bentobako.org/ubuntu-ocaml-status/raw/ In particular there is a colored comparison, package per package: http://bentobako.org/ubuntu-ocaml-status/raw/compare-testing-lucid.html Are there a lot of differents between Debian's ocaml 3.11.1-4 and 3.11.1-5? Would importing 3.11.1-5 in Lucid trigger an OCaml transition? Let me know if something else is needed. Lucid will be an Long Term Support (LTS) so having OCaml in good shape for that release would not be that bad. Regards, d. PS: I'm still not volunteering to be Ubuntu developer or take care of all OCaml's packages on Ubuntu but nobody seems to want to take the job and Lucid is an LTS. (sigh) -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#564158: [libmlpcap-ocaml-dev] Invalid payload in callback function when reading a trace with pcap_loop
Hello, 2010/1/8 Stéphane Glondu st...@glondu.net: Actually, pcap_payload embeds a pointer outside the ML heap (ML block with unaligned_tag). I guess it is the libpcap receive buffer. As such, it is not marshallable nor usable with regular string functions. However, unsafe_* variants work fine (see pcap_loop.ml example for example). If you want to use it as a regular string, you'll have to unsafe_blit the contents into another OCaml string yourself. Is this documented somewhere? I don't remember having seen this when I used mlpcap (a long time ago). Regards, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Transition to OCaml 3.11.1 in Ubuntu Karmic Koala completed!
Hello, I am very pleased to announce that transition to OCaml 3.11.1 in Ubuntu Karmic is now completed! http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ocaml_transition_monitor.html Many thanks to (in order of appearance): * Ubuntu side: James Wetsby Andrea Gasparini Michael Bienia Steve Kowalik Jonathan Riddell Stefan Lesicnik * Debian side: Stefano Zacchiroli Stéphane Glondu Mehdi Dogguy Sylvain Le Gall And of course all the Debian and Ubuntu developers that work so hard on OCaml support and have helped me doing this transition! Currently, most of OCaml packages is Debian unstable are available in Karmic: http://bentobako.org/ubuntu-ocaml-status/raw/compare-unstable-karmic.html [ I have requested a synchronization for react and pgocaml. ] Sincerely yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Build issue with why and libfloat-coq
Hello, For transition to OCaml 3.11.1 in Ubuntu Karmic, the only remaining package having an issue is why. It fails to build because its dependency libfloat-coq is not installable: The following packages have unmet dependencies: libfloat-coq: Depends: coq-8.2-1+3.11.0 but it is not installable http://launchpadlibrarian.net/30368068/buildlog_ubuntu-karmic-amd64.why_2.18.dfsg-5_FAILEDTOBUILD.txt.gz The current coq-float source package in Karmic is 1:8.2-1.2-3: https://launchpad.net/ubuntu/karmic/+source/coq-float/1:8.2-1.2-3 The current coq source package in Karmic is 8.2.pl1+dfsg-2: https://launchpad.net/ubuntu/karmic/+source/coq/8.2.pl1+dfsg-2 I'm not quite sure of the blocking point. Is it coq? coq-float? A synchronization is needed or just a re-compilation? I would appreciate any help. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Build issue with why and libfloat-coq
Hello Stéphane, 2009/8/18 Stéphane Glondu st...@glondu.net: It looks like it's coq-float. It depends on Coq ABI, which is $COQVERSION-$OCAMLVERSION. It must be recompiled before why. Thank you for the explanation. Michael Biena has triggered a recompilation of the packages in the proper order. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[Karmic transition to 3.11.1] Issue with ocaml-libvirt and ocaml-gettext
Hello, We cannot synchronize OCaml ocaml-libvirt from unstable to karmic because ocaml-libvirt build-depends on libgettext-ocaml-dev 0.3.2-2 and only ocaml-gettext 0.3.2-2 is available in Debian. http://packages.qa.debian.org/o/ocaml-gettext.html http://git.debian.org/?p=pkg-ocaml-maint/packages/ocaml-libvirt.git;a=blob;f=debian/control;h=1f6c67f0e2c46ef4d296892779665c58d87e30f9;hb=HEAD Any idea? Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Karmic transition to 3.11.1] Issue with ocaml-libvirt and ocaml-gettext
Hello Mehdi and Sylvain, Sylvain Le Gall gil...@debian.org writes: The ( 0.3.2-2) is for transition and binNMU. The available version in debian is 0.3.2-2+b1. $ dpkg --compare-versions 0.3.2-2+b1 0.3.2-2 echo OK OK You can downgrade the build-depends to = 0.3.2 for ubuntu if you like. Ok. Thank you. Yours, d. -- GPG/PGP key: A3AD7A2A David MENTRE dmen...@linux-france.org 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[Ubuntu transition to 3.11.1] Specific change on lablgtk2
Hello, We have started transition to 3.11.1 in Ubuntu Karmic and I'm looking at Ubuntu specific changes to see if they should be merged / keep separate in Ubuntu. For lablgtk2, the change is the following: --- 2.12.0-2/debian/changelog 2009-05-19 21:22:27.0 +0100 +++ 2.12.0-2ubuntu1/debian/changelog2009-05-19 21:20:16.0 +0100 @@ -1,3 +1,10 @@ +lablgtk2 (2.12.0-2ubuntu1) karmic; urgency=low + + * debian/patches/: added ubuntu_failtobuildfromsources.dpatch that fix a +FTBFS caused by a missing libgnomeui/libgnomeui.h (LP: #378282) + + -- Andrea Gasparini ga...@yattaweb.it Tue, 19 May 2009 11:33:25 +0200 + With: --- 2.12.0-2/debian/patches/ubuntu_failtobuildfromsources.dpatch 1970-01-01 01:00:00.0 +0100 +++ 2.12.0-2ubuntu1/debian/patches/ubuntu_failtobuildfromsources.dpatch 2009-05-19 21:20:16.0 +0100 @@ -0,0 +1,17 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## +## DP: due to some changes to gnome headers, lablgtk2 fail to build +## DP: in ubuntu environment. + +...@dpatch@ +diff -u lablgtk2-2.12.0.orig/src/ml_panel.c lablgtk2-2.12.0/src/ml_panel.c +--- lablgtk2-2.12.0.orig/src/ml_panel.c lablgtk2-2.12.0/src/ml_panel.c +@@ -23,6 +23,7 @@ + #include string.h + + #include libgnomeui/gnome-client.h ++#include libgnomeui/libgnomeui.h + #include panel-applet.h + + #include caml/mlvalues.h Should this patch be included in Debian's lablgtk2? Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[Ubuntu transition to 3.11.1] Specific changes on graphviz
Hello, Same issue as my previous email, this time regarding graphviz. Ubuntu applies following patch. Should it be integrated in Debian's version of the package or keep separated in Ubuntu? https://patches.ubuntu.com/g/graphviz/graphviz_2.20.2-3ubuntu3.patch diff -pruN 2.20.2-3/debian/changelog 2.20.2-3ubuntu3/debian/changelog --- 2.20.2-3/debian/changelog 2009-06-15 13:38:54.0 +0100 +++ 2.20.2-3ubuntu3/debian/changelog2009-06-15 13:20:50.0 +0100 @@ -1,3 +1,40 @@ +graphviz (2.20.2-3ubuntu3) karmic; urgency=low + + * No-change rebuild against current OCaml. (LP: #383574) + + -- Martin Pitt martin.p...@ubuntu.com Mon, 15 Jun 2009 11:16:14 +0200 + +graphviz (2.20.2-3ubuntu2) jaunty; urgency=low + + * debian/control: +- Dropped build dependency on python2.4-dev +- Added build dependency on python2.6-dev (LP: #338553) +- Added XS-Python-Version: all +- Updated description of libgv-python to drop references to python2.4 and + python2.5 + * debian/rules: +- Included python.mk +- Load PYTHON_VERSIONS with default version instead of all versions +- Enable generic python support in configure (parameter --enable-python) + call and disable python2.4 (--enable-python24) support +- Install the generic python support and 2.5 support instead of 2.4 and 2.5 + + -- Fabrice Coutadeur coutade...@gmail.com Thu, 26 Mar 2009 04:35:09 + + +graphviz (2.20.2-3ubuntu1) jaunty; urgency=low + + * Merge with Debian unstable; remaining Ubuntu changes: +- Build against guile 1.8 instead of 1.6. (forwarded to Debian #493974) +- Fix gs-common build dependency to ghostscript. (forwarded to + Debian #504569) +- Update build dep libltdl3-dev to libltdl7-dev. (forwarded to + Debian #504571) + * Build against lua 5.1 instead of 5.0. This drops this Debian delta and +moves Ubuntu towards the newer lua version, which we need to do at some +point anyway. + + -- Martin Pitt martin.p...@ubuntu.com Wed, 05 Nov 2008 09:54:54 +0100 + graphviz (2.20.2-3) unstable; urgency=high * Backport patch to fix a stack overflow in the graph parser, reported diff -pruN 2.20.2-3/debian/control 2.20.2-3ubuntu3/debian/control --- 2.20.2-3/debian/control 2009-06-15 13:38:54.0 +0100 +++ 2.20.2-3ubuntu3/debian/control 2009-06-15 13:20:50.0 +0100 @@ -1,12 +1,14 @@ Source: graphviz Section: graphics Priority: optional -Maintainer: Cyril Brulebois k...@debian.org +Maintainer: Ubuntu Core Developers ubuntu-devel-disc...@lists.ubuntu.com +XSBC-Original-Maintainer: Cyril Brulebois k...@debian.org Standards-Version: 3.8.0 -Build-Depends: tk8.5-dev, tcl8.5-dev, debhelper (= 5), libfreetype6-dev, zlib1g-dev, libjpeg62-dev, libpng12-dev, libxaw7-dev, bison, flex, autotools-dev, pdksh, libexpat1-dev, libfontconfig1-dev, libltdl3-dev, swig, libperl-dev, libgd2-noxpm-dev (= 2.0.35), quilt (= 0.40), groff-base, gs-common, lua5.1, liblua5.1-0-dev, ruby, ruby1.8-dev, php5-dev, php5-cli, ocaml-nox, python2.4-dev, python2.5-dev, python-minimal, libcairo2-dev, libpango1.0-dev, guile-1.6-dev, d-shlibs, python-support, chrpath +Build-Depends: tk8.5-dev, tcl8.5-dev, debhelper (= 5), libfreetype6-dev, zlib1g-dev, libjpeg62-dev, libpng12-dev, libxaw7-dev, bison, flex, autotools-dev, pdksh, libexpat1-dev, libfontconfig1-dev, libltdl7-dev, swig, libperl-dev, libgd2-noxpm-dev (= 2.0.35), quilt (= 0.40), groff-base, ghostscript, lua5.1, liblua5.1-0-dev, ruby, ruby1.8-dev, php5-dev, php5-cli, ocaml-nox, python2.5-dev, python2.6-dev, python-minimal, libcairo2-dev, libpango1.0-dev, guile-1.8-dev, d-shlibs, python-support, chrpath Vcs-Git: git://git.debian.org/git/collab-maint/graphviz.git Vcs-Browser: http://git.debian.org/?p=collab-maint/graphviz.git Homepage: http://www.graphviz.org/ +XS-Python-Version: all Package: graphviz Architecture: any @@ -98,7 +100,7 @@ Description: Python bindings for graphvi Graphviz is a set of graph drawing tools. See the description of the graphviz package for a full description. . - This package contains the Python (2.4 and 2.5) bindings. + This package contains the Python bindings. Package: libgv-ruby Architecture: any diff -pruN 2.20.2-3/debian/rules 2.20.2-3ubuntu3/debian/rules --- 2.20.2-3/debian/rules 2009-06-15 13:38:54.0 +0100 +++ 2.20.2-3ubuntu3/debian/rules2009-06-15 13:20:50.0 +0100 @@ -6,6 +6,7 @@ #export DH_VERBOSE=1 include /usr/share/quilt/quilt.make +include /usr/share/python/python.mk # Get build platform info export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) @@ -25,7 +26,7 @@ LUA_PACKAGE = $(CURDIR)/debian/lib DEV_PACKAGE = $(CURDIR)/debian/libgraphviz-dev -PYTHON_VERSIONS = $(shell pyversions -s) +PYTHON_VERSIONS = $(shell pyversions -d) PYTHON_PACKAGE= $(CURDIR)/debian/libgv-python RUBY_VERSION = 1.8 @@ -62,7 +63,7 @@ configure-stamp: --enable-lua \ --enable-ocaml \ --enable-php
[Ubuntu transition to 3.11.1] Specific changes on ocaml-bjack
Hello,
Same issue as my previous email, this time regarding ocaml-bjack.
Ubuntu specific patch follows. Should it be integrated in Debian or
keep separate in Ubuntu?
https://patches.ubuntu.com/o/ocaml-bjack/ocaml-bjack_0.1.2-1ubuntu1.patch
diff -pruN 0.1.2-1/configure 0.1.2-1ubuntu1/configure
--- 0.1.2-1/configure 2009-02-17 18:31:45.0 +
+++ 0.1.2-1ubuntu1/configure2009-06-08 08:18:52.0 +0100
@@ -3233,7 +3233,7 @@ echo ${ECHO_T}yes 6; }
:
fi
-LIBS=$LDFLAGS -lsamplerate
+LIBS=$LIBS -lsamplerate
if test $OCAMLOPT = no ; then
BEST=byte
diff -pruN 0.1.2-1/configure.ac 0.1.2-1ubuntu1/configure.ac
--- 0.1.2-1/configure.ac2009-02-17 18:31:45.0 +
+++ 0.1.2-1ubuntu1/configure.ac 2009-06-08 08:18:52.0 +0100
@@ -108,7 +108,7 @@ AC_SUBST([jack_LDFLAGS])
# Check for samplerate
PKG_CHECK_MODULES(samplerate, samplerate = 0.0.15)
-LIBS=$LDFLAGS -lsamplerate
+LIBS=$LIBS -lsamplerate
if test $OCAMLOPT = no ; then
BEST=byte
diff -pruN 0.1.2-1/debian/changelog 0.1.2-1ubuntu1/debian/changelog
--- 0.1.2-1/debian/changelog2009-06-08 08:21:55.0 +0100
+++ 0.1.2-1ubuntu1/debian/changelog 2009-06-08 08:18:52.0 +0100
@@ -1,3 +1,13 @@
+ocaml-bjack (0.1.2-1ubuntu1) karmic; urgency=low
+
+ * Merge from debian unstable, remaining changes: (LP: #384631)
+- configure{.ac}:
+ - Use LIBS instead of LDFLAGS when redefining LIBS
+(fixes a FTBFS).
+ * Fixes: LP: #383576
+
+ -- Andreas Moog am...@ubuntu.com Mon, 08 Jun 2009 00:10:22 +0200
+
ocaml-bjack (0.1.2-1) unstable; urgency=low
* New Upstream Version.
@@ -14,6 +24,13 @@ ocaml-bjack (0.1.1-2) experimental; urge
-- Romain Beauxis to...@rastageeks.org Sat, 13 Dec 2008 23:12:27 +0100
+ocaml-bjack (0.1.1-1ubuntu1) intrepid; urgency=low
+
+ * configure{,.ac}: Use LIBS instead of LDFLAGS when redefining LIBS
+(fixes a FTBFS).
+
+ -- Michael Bienia ge...@ubuntu.com Sun, 27 Jul 2008 15:02:59 +0200
+
ocaml-bjack (0.1.1-1) unstable; urgency=low
* New upstream release, fixes typo in caml_bjack_open_byte(s)
Yours,
david
--
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Ubuntu transition to OCaml 3.11.1
Hello, For information, Ubuntu Karmic is transitioning to OCaml 3.11.1. The whole plan is here: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-July/009088.html We are currently in round 2. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Ubuntu transition to 3.11.1] Specific changes on camlimages
Hello Mehdi, 2009/7/24 Mehdi Dogguy me...@dogguy.org: These changes are included in the latest Debian package (1:3.0.1-2). So, IMO, you can just synchronize directly the package. Ok. Thanks! Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Ubuntu transition to 3.11.1] Specific change on lablgtk2
2009/7/24 Mehdi Dogguy me...@dogguy.org: Already done in (2.12.0-3). Ok. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Migrating OCaml to 3.11.1 in Karmic?
[ Added in Cc: Debian OCaml Maintainers for info. ] Hello Iain, 2009/7/20 Iain Lane la...@ubuntu.com: [ About transition 3.11.0 - 3.11.1 in Karmic. ] Let's do it (IMO). If you could write a mail detailing what needs to be done, Do following operations in 6 rounds. Start round /n/ once round /n+1/ is finished. In the following: * synchronize: synchronize source package from Debian unstable to Ubuntu karmic; * recompile: recompile the source package in Karmic; * manual_check: source package modified in both Debian and Ubuntu. One needs to manual check if the Debian package should be imported, modified or not. # Round 1: 1 outdated source package(s) * cancel in sync-blacklist.txt # dmentre, avoid uncoordinated ocaml transition; LP: #387943. * synchronize ocaml (3.11.0-5 - 3.11.1-2) # Round 2: 29 outdated source package(s) synchronize camlp5 (5.10-3 - 5.12-1) synchronize headache (1.03-15 - 1.03-17) synchronize hevea (1.10-7 - 1.10-8) synchronize hlins (0.39-14 - 0.39-15) synchronize jocaml (3.11.0-3 - 3.11.1-1) synchronize menhir (20090204.dfsg-2 - 20090505.dfsg-1) synchronize mlgmp (20021123-14 - 20021123-15) synchronize mlpost (0.6-2 - 0.6-3) synchronize ocamlduce (3.11.0.0~rc1-2 - 3.11.1.0-1) synchronize ocamlwc (0.3-6 - 0.3-7) synchronize ocamlweb (1.37-10 - 1.37-11) synchronize planets (0.1.13-8 - 0.1.13-9) synchronize polygen (1.0.6.ds2-7 - 1.0.6.ds2-8) synchronize spamoracle (1.4-13 - 1.4-14) recompile camlidl (1.05-12) recompile camlzip (1.04-4) recompile cothreads (0.10-2) recompile cryptokit (1.3-13) recompile facile (1.1-6.3) recompile findlib (1.2.4-2) recompile lablgl (1.04-2) recompile numerix (0.22-5) recompile ocaml-syck (0.1.1-3) recompile ocamlagrep (1.0-10) recompile ocamlpam (1.1-3) recompile perl4caml (0.9.5-2) recompile pycaml (0.82-10) recompile uuidm (0.9.3-2) recompile xml-light (2.2-11) # Round 3: 57 outdated source package(s) synchronize bibtex2html (1.94-1 - 1.94-2) synchronize camomile (0.7.1-5 - 0.7.2-1) synchronize ledit (2.01-3 - 2.01-4) synchronize ocaml-bitstring (1.9.7-2 - 2.0.0-4) synchronize ocaml-bjack (0.1.2-1ubuntu1 - 0.1.2-2) synchronize ocaml-getopt (0.0.20040811-8 - 0.0.20040811-9) synchronize ocaml-libvirt (0.4.4.2-1 - 0.6.1.0-1) synchronize ocaml-res (3.1.1-2 - 3.2.0-1) synchronize ocaml-sqlite3 (1.4.0-2 - 1.5.1-1) synchronize ocaml-text (0.2-1 - 0.2-2) synchronize ocamlcreal (0.7-4 - 0.7-5) synchronize otags (3.09.3-2 - 3.09.3-3) synchronize pcre-ocaml (5.15.1-2 - 6.0.1-1) recompile calendar (2.01.1-5) recompile camlbz2 (0.6.0-3) recompile cryptgps (0.2.1-6) recompile extlib (1.5.1-3) recompile gmetadom (0.2.6-3) recompile mlpcap (0.9-14) recompile mysql-ocaml (1.0.4-6) recompile ocaml-alsa (0.1.3-3) recompile ocaml-ao (0.1.9-3) recompile ocaml-benchmark (0.9-1) recompile ocaml-curses (1.0.2-3) recompile ocaml-dbus (0.07-1) recompile ocaml-dtools (0.1.6-3) recompile ocaml-expat (0.9.1+debian1-5) recompile ocaml-fileutils (0.3.0-14) recompile ocaml-gavl (0.1.1-2) recompile ocaml-inotify (0.9-1) recompile ocaml-ladspa (0.1.1-3) recompile ocaml-mad (0.3.5-2) recompile ocaml-magic (0.7.3-4) recompile ocaml-ogg (0.3.0-1) recompile ocaml-portaudio (0.1.2-2) recompile ocaml-pulseaudio (0.1.0-3) recompile ocaml-samplerate (0.1.0-1) recompile ocaml-sha (1.5-2) recompile ocaml-shout (0.2.6-3) recompile ocaml-soundtouch (0.1.4-3) recompile ocaml-ssl (0.4.3-2) recompile ocaml-taglib (0.1.3-1) recompile ocaml-xmlplaylist (0.1.1-4) recompile ocamlgsl (0.6.0-5) recompile ocamlsdl (0.7.2-10) recompile ocurl (0.5.1-1) recompile ounit (1.0.3-2) recompile pagodacf (0.10-2) recompile postgresql-ocaml (1.10.3-1) recompile syslog-ocaml (1.4-4) recompile type-conv (1.6.7-2) recompile ulex (1.1-1) recompile ulex0.8 (0.8-8) recompile xmlm (1.0.1-1) recompile xstr (0.2.1-20) manual_check graphviz (2.20.2-3, 2.20.2-3ubuntu3) manual_check lablgtk2 (2.12.0-3, 2.12.0-2ubuntu1) # Round 4: 22 outdated source package(s) synchronize ara (1.0.26 - 1.0.27) synchronize bin-prot (1.2.10-1 - 1.2.14-2) synchronize cmigrep (1.5-3 - 1.5-4) synchronize coq (8.2-1+dfsg-1 - 8.2.pl1+dfsg-2) synchronize dose2 (1.4.1-1 - 1.4.1-3) synchronize ocaml-reins (0.1a-1 - 0.1a-2) synchronize ocamlgraph (1.0-2 - 1.1-1) synchronize sexplib310 (4.2.6-3 - 4.2.11-2) recompile cairo-ocaml (20090223-1) recompile cameleon (1.9.18.svn20090302+691-1) recompile lablgtkmathview (0.7.8-4) recompile lwt (1.1.0-3) recompile ocaml-csv (1.1.7-1) recompile ocaml-duppy (0.3.0-1) recompile ocaml-gettext (0.3.2-2) recompile ocaml-speex (0.1.1-2) recompile ocaml-theora (0.1.1-2) recompile ocaml-vorbis (0.5.0-1) recompile ocamlbricks (0.50.1-3) recompile ocamlnet (2.2.9-6) recompile ocamlodbc (2.15-4) manual_check camlimages (1:3.0.1-2, 1:3.0.1-1ubuntu1) # Round 5: 11 outdated source package(s) synchronize ocaml-batteries (0.20090405+beta1-1 - 0.20090405+beta1-2) synchronize ocsigen (1.1.0-2 - 1.2.0-2) recompile cduce (0.5.3-2) recompile janest-core (0.5.2-1) recompile json-wheel (1.0.6-1) recompile ocaml-http
Re: Migrating OCaml to 3.11.1 in Karmic?
Hello Scott, 2009/7/21 Scott Kitterman ubu...@kitterman.com: How long do you expect? A similar transition took 4 weeks in Debian. Can you finish by feature freeze? If we start now, we can hopefully finish by mid-August. As feature freeze is the 27th of August, I think this is doable. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
OCaml 3.11.1 transition nearly finished?
Hello, Can we say that the OCaml 3.11.1 transition in Debian is finished or very close to? Only camlpdf seems to be lacking. http://debian.glondu.net/monitor/ocaml/ocaml_transition_monitor.html Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Migrating OCaml to 3.11.1 in Karmic?
Hello, Currently Karmic ships with OCaml compiler and libraries for OCaml version 3.11.0. Debian has nearly finished its transition to OCaml 3.11.1, only camlpdf is missing[1]. Should we do the same transition to OCaml 3.11.1 for Karmic? The transition takes 6 rounds[2], there are 124 source packages to synchronize / recompile and the transition has taken about 4 weeks in Debian (24th of June until today). During this summer, I could handle / monitor such a transition during following time periods: * July, 21st - 31st; * August, 10th - 21st. It would be very nice to ship latest OCaml but I don't know if it still fits Karmic Release Schedule. If such a transition is agreed upon, as suggested by James Westby[3], I would need the help of an Ubuntu Developer to fulfil Sync requests and potentially an Ubuntu Archive maintainer if such a transition is too late[4]. Any volunteer? Sincerely yours, david [1] http://debian.glondu.net/monitor/ocaml/ocaml_transition_monitor.html [2] http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ocaml_transition_monitor.html [3] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-June/008667.html [4] As far as I know this is not the case, feature freeze being the 27th of August (https://wiki.ubuntu.com/KarmicReleaseSchedule). -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[ANN] All OCaml packages synchronised for OCaml 3.11.0 in Ubuntu Karmic
Hello, I'm pleased to announce that all OCaml packages made by Debian developers are now synchronized to OCaml 3.11.0 in Ubuntu Karmic: http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ocaml_transition_monitor.html Moreover, all packages[1] have the same version number in Debian Unstable and Ubuntu Karmic: http://bentobako.org/ubuntu-ocaml-status/raw/compare-unstable-karmic.html So Ubuntu Karmic, aka 9.10, to be released in October will ship with a full fledge OCaml 3.11.0! Many thanks to all Debian and Ubuntu developers involved. Regarding recently released OCaml 3.11.1, I'm not sure it will be ready for Karmic but it will be available in Karmic+1 and probably in a backport or through PPA. Sincerely yours, david [1] Except unison package, but the changes made in 2.27.57-2 revision should not impact users. http://packages.debian.org/changelogs/pool/main/u/unison/current/changelog#versionversion2.27.57-2 -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transition to OCaml 3.11.1... - and to /usr/lib/ocaml
Hello, On Tue, Jun 16, 2009 at 14:15, Stefano Zacchiroliz...@debian.org wrote: Eya, sorry for the delay. No problem with the transition, I agree with the proposed plan. Would it be possible to delay the import of the new packages in unstable after the 25th of June in order to avoid its import in Ubuntu? Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transition to OCaml 3.11.1... - and to /usr/lib/ocaml
Hello Stefano, On Tue, Jun 16, 2009 at 15:22, David MENTREdmen...@linux-france.org wrote: On Tue, Jun 16, 2009 at 15:16, Stefano Zacchiroliz...@debian.org wrote: Note that this does not mean I don't respect your work to keep OCaml in shape on Ubuntu; quite the contrary: I deeply respect it and I've always thanked you for that. But I see needs like yours coming (hopefully!) more and more frequently in the future, so it is the right moment to ask, Ubuntu side, a way to block automatic importing. Can you ask about its possibility? I'm going to ask the question. This is possible. I have opened the proper bug and I am waiting for the blocking to be done by ubuntu-archive people. For the record, the Colin Watson's response: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-June/008704.html Opened bug: https://bugs.launchpad.net/ubuntu/+source/ocaml/+bug/387943 The list of source packages to block: http://launchpadlibrarian.net/27992673/ocaml-src-pkg-to-block-list.txt Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transition to OCaml 3.11.1... - and to /usr/lib/ocaml
Hello Stefano, On Tue, Jun 16, 2009 at 18:35, Stefano Zacchiroliz...@debian.org wrote: On Tue, Jun 16, 2009 at 04:45:22PM +0200, David MENTRE wrote: This is possible. I have opened the proper bug and I am waiting for the blocking to be done by ubuntu-archive people. Wonderful, thanks! Please let us know when the block is in place. It is now in place. ;-) http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt (at the end) Several Ubuntu people where in favour of a transition to 3.11.1 in Karmic[1]. While I prefer right now to keep all packages at the same state, it is apparently not so difficult to undo the blocking, so we might decide to do the transition to Karmic in a near future. The Feature Freeze (i.e. very last date for an import) is the 27th of August. Yours, d. [1] Details in the bug: https://bugs.launchpad.net/ubuntu/+source/ocaml/+bug/387943 -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Splitting pgocaml.
Hello, On Mon, Jun 15, 2009 at 08:40, Sylvain Le Gallgil...@debian.org wrote: It is not a general purpose tools and -dev package have probably a lot of thing in common with this tool... And multiplying the number of packages for the same software is strongly disapproved by some users. ;-) Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transition to OCaml 3.11.1...
Hello Stéphane, On Fri, Jun 12, 2009 at 15:28, Stéphane Glondust...@glondu.net wrote: I suggest to ask the release team and proceed with uploading of ocaml to unstable right away (after their approval), then wait one week or so to figure out what needs sourceful upload and upload whatever is relevant, and then proceed with the binNMU. Regarding Ubuntu, the Debian Import Freeze is set to the 25th of June. After that date, packages can be synchronized upon request until the 13th of August. https://wiki.ubuntu.com/KarmicReleaseSchedule Currently, nearly all (i.e. except 3 packages) are on 3.11.0. According to your planning, it would mean that OCaml 3.11.1 would be uploaded now (12th of June) and all other packages rebuilt after the 23th of June. It could break the current OCaml status on Ubuntu. I don't know if massive rebuild of packages (binNMU???) is possible on Ubuntu. Why do you think of this? Of course, I would very much have OCaml 3.11.1 on Karmic but that might be difficult to do in such a short time frame. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transition to OCaml 3.11.1...
Hello Stéphane, On Fri, Jun 12, 2009 at 16:37, Stéphane Glondust...@glondu.net wrote: I don't know either how Ubuntu manages this kind of task For the record, I've started a thread regarding those issues in Ubuntu: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-June/thread.html#8656 Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transition to OCaml 3.11.1...
Hello Sylvain, On Fri, Jun 12, 2009 at 20:07, Sylvain Le Gallgil...@debian.org wrote: I think we are too tigh regarding time. I prefer that Ubuntu ship a good 3.11.0 release than to have to fight for months to get a 3.11.1. I need to think a bit more about this but looking at the amount of work I should do or things I should learn for doing this job[1], I would prefer not to do that in a hurry. Moreover, summer time is coming and I plan to take some holidays. ;-) So right now I'm also for keeping 3.11.0 in Karmic and doing 3.11.1 in Karmic+1. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Status of OCaml packages on Ubuntu Karmic - 2009-06-10
Hello, After some rebuilds, the status of OCaml packages in Ubuntu Karmic is in much better shape: http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ocaml_transition_monitor.html Currently, only 3 packages have issues (over 124): * pycaml: a new version (0.82-10) has been uploaded in Debian which should fix the issue with Python 2.6 in Karmic after automatic import. I'm waiting for the automatic import. * graphviz: a rebuild is necessary, I have opened a bug (LP #383574) and I'm waiting for an Ubuntu Main maintainer to trigger the rebuild. * nurpawiki: a rebuild is necessary, I have opened a bug (LP #385486) and I'm waiting for an Ubuntu Universe maintainer to trigger a rebuild. After that, Karmic will have all up-to-date OCaml packages \o/ until transition to OCaml 3.11.1. :) Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
QA for OCaml package: a few ideas
Hello, After monitoring the build and status of OCaml packages in Ubuntu, I know need to look at a way to test that the packages really work. So, I'm thinking at a kind of script that would: - trigger an install or update of the binary package[1] and verifies the package is correctly installed; - launch a simple test of the program (at least prog --version or prog --help) for both byte code and native code versions. I'm thinking of writing a simple OCaml program to do that, probably with OUnit (or similar framework). What do you think of it? Anybody has done similar things? Yours, david [1] BTW, is there a list of all OCaml binary packages? -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: QA for OCaml package: a few ideas
Hello Stéphane, On Wed, Jun 10, 2009 at 10:40, Stéphane Glondust...@glondu.net wrote: Do you know piuparts? No. Thank you for the pointer. And BTW, I guess many packages would have already been (kind of) tested when their reverse-dependencies have been built... Well... I already noticed in the past that all byte code packages in Ubuntu where corrupted due to Ubuntu-specific changes. So there is nothing better than running the final program (or calling the final library). Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: QA for OCaml package: a few ideas
Hello Stefano, On Wed, Jun 10, 2009 at 12:40, Stefano Zacchiroliz...@debian.org wrote: So, I'm thinking at a kind of script that would: - trigger an install or update of the binary package[1] and verifies the package is correctly installed; - launch a simple test of the program (at least prog --version or prog --help) for both byte code and native code versions. I think this approach will be quite pointless: --help and --version are standard in GNU(-like) apps, but are not there very often for OCaml programs. Sorry, I wasn't precise enough. I wanted to say: write a specific set of tests *per binary package* that runs the binaries. So it could be -version or --version or whatever depending of the package. The appropriate place where to do that however, is not an external program, but something that is integrated in the build process and which is automatically triggered on the appropriate packages without need package-specific actions. Today, this place is the dh-ocaml package. I'm not so sure. More exactly, I think the two approaches are complementary. While the dh-ocaml tests could be more generic and thus automatic, they won't test the final binary, installed in the proper place in /usr with associated configuration file. Well, apparently there is not much done in this area. I'll try to dig a bit more and show you anything I might have more concrete. Yours, d. PS: All OCaml developers are not that allergic to unit tests. In my own program I have execution time unit test per module. ;-) -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: QA for OCaml package: a few ideas
Hello Stefano, On Wed, Jun 10, 2009 at 15:19, Stefano Zacchiroliz...@debian.org wrote: Then, IMO, you should go back to step 1 of my answer. Given that you are going to need per-package work anyhow, it would be better to push that work upstream, providing per-package patches that do that. Ok, that makes sense. But I'm wondering if such test-per-package would not clutter the package with unneeded (except for tests) binaries and/or files. On the other side, one could use examples and other provided files. I suppose some experiments would say if this is the case or not. The other side of the coin is to have a kind of standard to call all the tests of a package and interpret the results. Something like /usr/bin/program-run-all-tests. If I want to monitor the 246 OCaml packages in Debian/Ubuntu, I don't want to have 246 different ways to call the tests and get the results. Once again, some field experiment will tell what kind of requirements is needed. Many thanks to all of you for your inputs. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
New status package to compare Debian and Ubuntu OCaml packages
Hello, I made a new status page that shows version number of OCaml packages for two distributions and a given OCaml release: https://bentobako.org/ubuntu-ocaml-status/raw/compare-3.11.0-unstable-karmic.html Hopefully the coloured output will help to spot any issues in Ubuntu. Source code is available: http://www.linux-france.org/cgi-bin/hgwebdir.cgi/ubuntu-ocaml-status?f=a08ca3dcae73;file=raw/compare-versions.py Yours, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531806: pycaml fails to build with Python 2.6
Package: pycaml Version: 0.82-8 Hello, pycaml package fails to build with Python 2.6 on Ubuntu Karmic. Here is the build log: http://launchpadlibrarian.net/27403133/buildlog_ubuntu-karmic-i386.pycaml_0.82-9_FAILEDTOBUILD.txt.gz Here are the explanations about that bug of Max Bowsher m...@f2s.com : if you look at the build log, the error is: pycaml_ml.c:1151: error: 'PyImport_ImportModuleEx' undeclared here (not in a function) If you dig around a bit, you find that in Python 2.6, this is strictly a #define, which is incompatible with pycaml_ml.c's use of it - whereas in Python 2.5, it was also provided as a real entry point for compatibility. Rather annoyingly, if you dig into Python's svn repository, it looks like this compatibility provision may have been *accidentally* reverted - http://svn.python.org/view?view=revrevision=59678, look at the changes to import.c and import.h. Accidentally or not, it looks like pycaml will need to be adapted to not use that function. Max. Yours, d. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.14.2 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages pycaml depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii ocaml-base-nox [ocaml-base-no 3.10.2-3 Runtime system for OCaml bytecode ii python2.5 2.5.2-15 An interactive high-level object-o Versions of packages pycaml recommends: ii ocaml-nox [ocaml-nox-3.10.2] 3.10.2-3 ML language implementation with a pycaml suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Issues with pycaml in Karmic (was: Re: Adaptation of ocaml_transition_monitor to Ubuntu)
Hello Dmitrijs, On Wed, Jun 3, 2009 at 15:23, Dmitrijs Ledkovs dmitrij.led...@gmail.com wrote: Not an expert nor a DD nor anything in Ubuntu. But this could be either a gcc4.4 transition/bug or a python2.6 et al bug. Does exactly this package compile fine in Sid Jaunty if yes than most likely gcc4.4 related. It builds in Jaunty (not exactly the same package -8ubuntu1 instead of -9): https://launchpad.net/ubuntu/jaunty/+source/pycaml/+builds It compiles in Sid (but using gcc-4.3 and python 2.5): https://buildd.debian.org/pkg.cgi?pkg=pycaml Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Issues with pycaml in Karmic (was: Re: Adaptation of ocaml_transition_monitor to Ubuntu)
On Wed, Jun 3, 2009 at 16:22, David MENTRE dmen...@linux-france.org wrote: It builds in Jaunty (not exactly the same package -8ubuntu1 instead of -9): Here is the changelog of Ubuntu specific changes in Intrepid and Jaunty: pycaml (0.82-8ubuntu1) intrepid; urgency=low * Apply fix from Debian OCaml Group SVN (rev 5688): + Add missing dependency on ocaml-interp to pycaml. + Move dllpycaml_stubs.so to the directory where ocaml looks for it. * debian/control: + Modify Maintainer value to match DebianMaintainerField spec. -- Michael Bienia email address hidden Tue, 27 May 2008 19:21:20 +0200 Here is the patch: https://patches.ubuntu.com/by-release/ubuntu/p/pycaml/pycaml_0.82-8ubuntu1.patch Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Adaptation of ocaml_transition_monitor to Ubuntu
Hello, I have adapted Stephane Glondu's ocaml_transition_monitor[1] to Ubuntu: http://bentobako.org/ubuntu-ocaml-status/transition_monitor/ocaml_transition_monitor.html This daily generated web page displays status of various OCaml packages on Ubuntu Karmic. Currently 20 of 122 packages are failing to build against OCaml compiler 3.11.0 in Karmic. I added the above monitor on the OCaml Task Force page on Debian wiki: http://wiki.debian.org/Teams/OCamlTaskForce Sincerely yours, david [1] http://glondu.net/debian/ocaml_transition_monitor.html -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xmlm_1.0.1-1_amd64.changes is NEW
Hello Romain, On Thu, May 14, 2009 at 12:18, Debian Installer instal...@ftp-master.debian.org wrote: OCaml xml manipulation module Xmlm allows the OCaml programmer to manipulate xml data. Its complexity is half-way between the easy xml-light module and a full parsing of xml data. I am half surprised by the packaging of Xmlm as the recommended way to use it is to copy/paste the two source files in your source tree (I'm using it). Why package it at all? Sincerely yours, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xmlm_1.0.1-1_amd64.changes is NEW
Hello Romain, Thank you for the explanations. Dependencies are nice to have (code reuse, security fix as you underlined it) but can be a nightmare if they are two numerous. This is usually not the case on Debian and Ubuntu thanks to Debian developers but this is not the case on other distributions. Anyway, this general issue is not related to Debian packaging. ;-) On Thu, May 14, 2009 at 12:55, Romain Beauxis to...@rastageeks.org wrote: As a side note, xmlm includes a META file, which adds support for findlib, which is mainly used to compile against external ocaml modules. This seems to indicate that xmlm's upstream author has nothing against doing so, then.. However, I found several things that should be fixed in order to properly support findlib and external compilation, and will send a patch to the author soon. Did not know about that. Nice to have, thanks. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xmlm_1.0.1-1_amd64.changes is NEW
On Thu, May 14, 2009 at 15:01, Romain Beauxis to...@rastageeks.org wrote: Hence, shipping ocaml modules with findlib added in debian can also lead to issues if it is not added upstream at some point. Seeing that xmlm is currently maintained and that it has a support for findlib, as well as a simple way to upgrade code was clearly the main motivation for me on that topic.. Quite interesting discussion. Thank you for the explanation. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
New comparison between Ubuntu's Karmic Koala and Debian's Sid
[ I'm re-submitting through GMail because for whatever reason lists.debian.org is blocking my ISP Free.fr. ] Hello, Karmic Koala has officially started. The Debian Import Freeze is set to June the 25th: https://wiki.ubuntu.com/KarmicReleaseSchedule I have updated my comparison page between Debian and Ubuntu releases regarding OCaml packages: http://bentobako.org/ubuntu-ocaml-status/raw/ Most notably there is now a comparison Unstable vs. Karmic: http://bentobako.org/ubuntu-ocaml-status/raw/unstable-vs-karmic.txt Currently, the OCaml packages seem at Jaunty level, i.e. the same as Lenny. Sincerely yours, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
List of patches applied to Debian OCaml packages in Ubuntu
Hello, I have extended my set of scripts with a list of patches applied to Debian OCaml packages into Ubuntu: http://bentobako.org/ubuntu-ocaml-status/raw/ubuntu-patches.html The list is divided into two sets: * Ubuntu modification patches: patches that make a real modification of the Debian package; * Ubuntu build patches (benign): patches that are only used to trigger a new build of the source package. As far as I know, they should be ignored. This list is generated automatically from https://patches.ubuntu.com so it should stay up-to-date with latest modifications in Ubuntu. Regarding the exact meaning of those patches: These patches are generated daily and contain the differences between an Ubuntu source package and the equivalent version of the same source in Debian. This means that the base of the patch for an Ubuntu 1.2-3ubuntu4 version will be the Debian 1.2-3 package, even if the Debian version is now 1.4-1. This hopefully makes the packages easier to merge. Where Ubuntu have packaged a new upstream themselves, noted by a revision beginning 0ubuntu the patch is from the first Debian revision of the same upstream version if available (so 1.2-0ubuntu1 will be compared from the Debian 1.2-1 package). Where not available, you will usually find that the base of the patch is the first common ancestor of both Ubuntu and Debian. Source: https://patches.ubuntu.com I will make a review of those patches and hopefully post relevant bug reports on Debian BTS (and merge Julien Cristau previous review on Mon, 13 Oct 2008). Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Ubuntu Karmic synchronization period with Debian sid: definitive schedule
Hello, The import period from Debian sid to Ubuntu Karmic is going to take place from April the 30th to June the 25th. Source: https://wiki.ubuntu.com/KarmicReleaseSchedule Sincerely yours, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Draft synchronization time-frame from Debian to Ubuntu
Hello, As a follow-up on a previous discussion regarding synchronization window from Debian to Ubuntu: https://lists.ubuntu.com/archives/ubuntu-motu/2009-February/005476.html Broadly speaking, the archive is likely to open for autosync in early May, and probably close in late June. These are far from official dates, but it's typically a week or two from release to archive open, and usually 6-8 weeks between archive open and Debian Import Freeze. If the transition is not expected to complete by mid-June or so, it is probably worth further coordination to ensure that any outstanding changes can be addressed shortly after Debian Import Freeze. I'll forward a precise release schedule when it will be available. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Status of OCaml packages on Debian and Ubuntu
Hello, David MENTRE dmen...@linux-france.org writes: But I'll try to start modestly: keep an eye on Ubuntu packages vs. Debian ones. I'll keep in mind the patches aspect though. Here is my first attempt: 1. A list of all package versions in Debian and Ubuntu: http://bentobako.org/ubuntu-ocaml-status/raw/raw-status-binaries.txt 2. A list of patched OCaml packages in Ubuntu: http://bentobako.org/ubuntu-ocaml-status/raw/raw-patched-packages.txt 3. A side-by-side comparison of OCaml packages for Debian Lenny and Ubuntu Jaunty: http://bentobako.org/ubuntu-ocaml-status/raw/lenny-vs-jaunty.txt In both lists, format is: debian-source-pkg distro-release ocaml-compiler package-version Those lists are updated daily. Let me know if you are thinking of additional information. Overall access: http://bentobako.org/ubuntu-ocaml-status/raw/ Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: switching to `ocamlc -where` = /usr/lib/ocaml/
Hello Stefano, On Mon, Feb 9, 2009 at 14:21, Stefano Zacchiroli z...@debian.org wrote: - the user community is split as: * mostly developer, which (quite understandably) always want to develop against the latest OCaml Or are stuck to the old version of OCaml available in Debian stable. ;-) Do you think I'm missing any important scenario which denotes the need of multiple OCaml versions at the same time? No. I think you're right. Practically though, that would just mean having findlib configured to look under /usr/local/lib/ABI/, Yes, keeping this behaviour seems essential to me. because OCaml by itself wont look anywhere else than under `ocamlc -where`, unless you provide -I. If you are aware of some other application which would require proper tuning to look under the right dir, please let us know. Sometimes, I had to modify the build system of some unpackaged OCaml libraries, mostly because they did not use findlib. I cannot give names right now, though. But I don't think the proposed changed (if /usr/local/lib/ABI/ is kept) would change anything. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: roadmap to OCaml 3.11 in Lenny+1
Hello Stefano, On Mon, Feb 9, 2009 at 14:37, Stefano Zacchiroli z...@debian.org wrote: On Mon, Feb 09, 2009 at 02:07:13PM +0100, David MENTRE wrote: - Resurrect modified scripts to have an overview of OCaml packages on Ubuntu. Uh? What does it mean? Please expand ... I once adapted Debian scripts to watch status of OCaml packages on Ubuntu: http://bentobako.org/tmp/ubuntu-only/debian-ocaml-status.html I need to modify them so as to provide a daily up-to-date status (no work for Debian developers here ;-). Well, Debian-side, we have no idea of what does a Debian-synchronization is, and IMO it shouldn't be required. Disclaimer: I'm a simple Ubuntu and Debian user. As far as I know: - There are no Ubuntu developers for OCaml; - Therefore, *all* OCaml packages in Ubuntu are direct import of Debian packages, *unmodified*[1]. Those packages are imported during as synchronization window with Debian sid opened at the beginning of each development period of a new Ubuntu release. For the coming Jaunty release, it was during November and December 2008: https://wiki.ubuntu.com/JauntyReleaseSchedule - As such, Debian developers have a *direct* control of which Ocaml packages are imported in Ubuntu or not, depending on what is available in Debian sid during the synchronization period. Outside those periods, only manual requests can allow sid packages to migrate to Ubuntu. As a direct consequence, if the Debian sid repository is in bad shape (e.g. OCaml major version transition to 3.11) during the Ubuntu synchronization window, the next Ubuntu will be released with very sub-optimal and maybe unusable OCaml. Political note: I do understand that Debian developers don't care about Ubuntu. This is not there distribution and they have enough work to care about in Debian itself. But Ubuntu is widely used, especially on the desktop. *I* think it would be positive for OCaml if Ubuntu OCaml packages would be in good shape. What is required is that people Ubuntu side send patches to our packages, or possibly directly commit to our repository in case they have alioth account (which we have never negated to people interested in working on Debian packages). As I said, I don't think any Ubuntu people are interested in OCaml packages in themselves. I'll try to make an inventory of Ubuntu patches on OCaml Debian packages. Nevertheless, if you want, we can while repackaging have a look at the diffs, but the patch flow should really go the other way around. I understand that. I am not a Debian or Ubuntu developer and I don't want to step in neither of those role. Sincerely yours, d. [1] A few packages are modified, but I think it is more related to other Ubuntu packages (Ubuntu wide changes) than real Ubuntu specific changes on OCaml packages. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian Ubuntu [was: roadmap to OCaml 3.11 in Lenny+1]
Hello Stefano, On Tue, Feb 10, 2009 at 10:47, Stefano Zacchiroli z...@debian.org wrote: Let me suggest one: if you find reasonable changes Ubuntu side which need to be integrated in Debian, submit a bugreport to the relevant Debian package, pointing to the Ubuntu change. I'll try to do that. This is an interesting aspect. Would you care about letting us know, via this list, when those synchronization window happen in the future? Yes, I'll let you know. Of course we cannot grant good conditions during them, but if it costs us nothing (or few efforts) it would be interesting to try be in shape during those windows. Nice! Political answer: I disagree with your statement that Debian developers don't care about Ubuntu. I do care, because I know it is a way to bring Debian efforts to a wider public; it is the same with all Debian derivatives, and especially with Ubuntu which is most widespread derivative. Excellent! Still, the game should be fair, I'm willing to do the job Debian-side, but I need collaboration Ubuntu-side, and you are helping with that. At least I'll try. ;-) I'll try to make an inventory of Ubuntu patches on OCaml Debian packages. Thanks! Please try, if possible, not to do that one shot, but to find a work-flow which is sustainable in the future. I doubt it can be automated, but you can build tools that help you in keeping us up to date on a regular basis. Yep. You're probably right. But I'll try to start modestly: keep an eye on Ubuntu packages vs. Debian ones. I'll keep in mind the patches aspect though. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: switching to `ocamlc -where` = /usr/lib/ocaml/
Hello Stefano, On Mon, Feb 9, 2009 at 10:07, Stefano Zacchiroli z...@debian.org wrote: I was thinking about doing this in two steps, but let's be clear for the sake of all the readers. Thanks! ;-) The proposal is to switch from having `ocamlc -where` = /usr/lib/ocaml/ABI/ to plain /usr/lib/ocaml/. The rationale is partly historical. In the beginning we used to hope in having multiple version of OCaml installed at the same time, hence we went for versioned directories. Now it is rather evident that it would be quite a waste of resources to have multiple version of OCaml supported, and also it is simply not useful for OCaml users. Apparently most of us/them just care about having the latest OCaml and nothing else. More specifically, only a single version of OCaml is available in a Debian (and thus Ubuntu) release. But if several OCaml compilers where available, I assume people would use them, if only to make one's software compatible with several OCaml releases. Of course, I understand that it would consume too much resources to maintain all OCaml infrastructure over several OCaml versions. BTW, isn't the versioned scheme useful during transitions in sid? Hence I do not see any reason to keep a versioned directory scheme, which just clutter the filesystem with no apparent good reason. Does any of you see any reason for keeping it? Well, the versioned directory scheme is useful for the /usr/local part, when you compile your own libraries and need to upgrade them after an OCaml compiler upgrade. I think this is much more clean with versioned directories. I don't know if it is related or not. So, my preference is still in not doing that now, but rather do a specific transition in the Lenny time frame. I'd like to receive comments on that. _If_ such a switch is made, the above proposal seems much cleaner to me. Sincerely yours, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: roadmap to OCaml 3.11 in Lenny+1
Hello, On Mon, Feb 9, 2009 at 11:10, Sylvain Le Gall gil...@debian.org wrote: On 08-02-2009, Stefano Zacchiroli z...@debian.org wrote: - ADD YOUR OWN HERE Please mention changes which are relatively low on impact, but can possibly improve things for the future. - Resurrect modified scripts to have an overview of OCaml packages on Ubuntu. - Synchronize with Ubuntu so as to have a decent OCaml environment (either 3.10 or 3.11) on next Ubuntu release. As far as I know, the next synchronization window with Debian will start at the end of April / beginning of May. Yours, d. -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: conversion to git
Hello, On Mon, Feb 2, 2009 at 17:19, Romain Beauxis to...@rastageeks.org wrote: I agree with you. Appart from the complexity that git induces, I still don't see at all the benefits of using a distributed CVS for simple source trees like packages. From my own developer perspective on simple source trees (mainly one trunk branch, nearly one developer), speed of DVCS tools is very convenient. All functions are nearly immediate. And it is very very easy to make a new branch, just to test some risky changes. I prefer Mercurial to GIT but both share those features. Of course, you still have a learning curve. I have never used GIT but for Mercurial and especially on simple trees, you only need to learn a few commands which are at the top of all tutorials (checkout, commit, log, diff, clone, push and pull). Sincerely yours, david -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Report on OCaml packages status on Ubuntu
Hello, A short email to signal that I made a report on the status of OCaml packages on Ubuntu: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-October/005880.html Despite putting debian-ocaml-maint in Cc:, my original email (and any further reply) did not reach the list. The SMTP servers of my ISP (free.fr) seem black-listed or something like that. If any Debian Developer can convince listmaster to take a look at this. In the meantime, I'll try to use my Gmail account (sigh). Regarding status of OCaml packages, OCaml in Intrepid Ibex is pretty well in synchronization with Lenny: * 6 packages would need a synchronization (https://bugs.launchpad.net/ubuntu/+source/janest-core/+bug/282278); * 3 packages are missing in Ubuntu; * 2 packages have been modified in Ubuntu (I haven't looked at them yet to see if those modifications need backport to Debian); * a few other packages are in various other state; * the vast majority of the other packages are the same as in Lenny. See my report for details. Let me know if you find any error. Sincerely yours, david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Report on OCaml packages status on Ubuntu
Hello Stefano, On Mon, Oct 13, 2008 at 11:34, Stefano Zacchiroli [EMAIL PROTECTED] wrote: Just to understand, have you already tried to contact listmaster, maybe without success, or not yet? I contacted listmaster, without any reply until now. This is an important thing to do, on one hand to check that those changes haven't introduced functional regressions (it happened in the past) and, as you observe, to check whether Debian might benefit from them. Sure, I just need to find some time to do it. :-) * a few other packages are in various other state; Can you please expand on this? Sure: = New version in Intrepid Ibex compared to Lenny, unmodified Intrepid package = facile intrepid 3.10.2 1.1-6.2 facile lenny 3.10.2 1.1-6.1+b2 And, in fact, 3 and not 2 packages have been modified in their Ubuntu version: = New version in Lenny compared to Intrepid Ibex, modified Intrepid package = graphviz intrepid 3.10.2 2.18-1ubuntu2 graphviz lenny 3.10.2 2.20.2-2 = Same version in Intrepid Ibex and Lenny, modified Intrepid package = ocaml-bjack intrepid 3.10.2 0.1.1-1ubuntu1 ocaml-bjack lenny 3.10.2 0.1.1-1 pycaml intrepid 3.10.2 0.82-8ubuntu1 pycaml lenny 3.10.2 0.82-8 Finally, a category you did not mention is OCaml-related packages available in Ubuntu, but not in Debian. Are there any instances of this category? Yes, apparently one: = Packages only available in Intrepid Ibex = ocaml-syck intrepid 3.10.2 0.1.1-2build2 Yours, d. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Report on OCaml packages status on Ubuntu
Hello Stéphane, On Mon, Oct 13, 2008 at 11:55, Stéphane Glondu [EMAIL PROTECTED] wrote: Have you tried: http://lists.debian.org/whitelist/ Yep, I'm subscribed to it. :-( Yours, d. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Page explaning naming of Debian packages?
On Fri, Oct 10, 2008 at 14:46, Stefano Zacchiroli [EMAIL PROTECTED] wrote: First of all it is not granted at all that two source packages with the same version number in two different distributions are the same. Within a single distro this is guaranteed (as the upload daemon would reject the latter upload), but cross distro it is not. It might be guaranteed by some Ubuntu policy wrt to Debian though, I don't know. Yes, it is guaranteed by Ubuntu's -XubuntuY additional version number in case of change: https://wiki.ubuntu.com/PackagingGuide/Complete#changelog Ubuntu and Debian have slightly different package versioning schemes to avoid conflicting packages with the same source version. If a Debian package has been changed in Ubuntu, it has ubuntuX (where X is the Ubuntu revision number) appended to the end of the Debian version. So if the Debian hello 2.1.1-1 package was changed by Ubuntu, the version string would be 2.1.1-1ubuntu1. If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g., 2.1.1-0ubuntu1). Even in that case, it is not granted that the resulting binary packages will be the same. In particular, some of the inter-package dependencies are computed dynamically during the build process, building them in different environment are likely to result in different dependencies. (sigh) There is no such thing as a simple job. (Tim Daly, of Axiom fame) BTW, the binNMUs which introduce the +b1 version suffixes, are just plain rebuilds which do not touch the source package. That's what I understood from Ralf's pointer. Thank you for the clarification. Yours, d. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Page explaning naming of Debian packages?
Hello Stefano and Ralf, On Fri, Oct 10, 2008 at 10:07, Stefano Zacchiroli [EMAIL PROTECTED] wrote: This one got through. So using the same From: email ([EMAIL PROTECTED]), my emails go through with Gmail but are blocked with my usual provider, free.fr. And of course I don't have any error messages. :-( Is there a page somewhere explaning the naming scheme of Debian packages? Naming scheme and versions are 2 different things. The version is explained in the policy, see Ralf comment for the trailing +bXX part. Ok. Thank you Ralf and Stefano for the pointers and explanations. In fact, I am more interested in the versions than in the naming scheme, sorry for not using the correct terms. I'm going to read those references and keep them at hand. Regarding naming note that you are quoting *source* package name, which are not necessarily the same as *binary* package names. I am aware of that, trying to follow the list for a few months now[1]. :-) However this is raising another question: I assume that if the source packages are the same (i.e. same version number) between Ubuntu and Debian, the derived binary packages will be the same. Is this a correct assumption? Yours, d. [1] But thank you for the pointer on Debian Ocaml policy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Page explaning naming of Debian packages?
[ Re-submitting from my Gmail account. Sorry for any duplicate. ] Hello, Is there a page somewhere explaning the naming scheme of Debian packages? I'm trying to understand version like: ocaml-reins 0.1a-1+b2 facile 1.1-6.1+b2 ocaml-expat 0.9.1+debian1-4+b1 Yours, david -- GPG/PGP key: A3AD7A2A David MENTRE [EMAIL PROTECTED] 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Issue to build libmlpcap-ocaml-dev examples on Debian Etch
Hello, I'm trying to build /usr/share/doc/libmlpcap-ocaml-dev/examples/ on Debian Etch 4.0. It does not compile when doing a make: $ make [...] ocamlfind ocamlc -package pcap -linkpkg -o misc misc.cmo /usr/bin/ld: cannot find -lcallback collect2: ld returned 1 exit status Error while building custom runtime system make: *** [misc] Error 2 On my system, the only libcallback I have is /usr/lib/libcallback.so.0.0.0. I tried to add /usr/lib/ path for libraries but it does not help: $ ocamlfind ocamlc -verbose -ccopt -L/usr/lib/ -package pcap -linkpkg -o misc misc.cmo Effective set of compiler predicates: pkg_pcap,autolink,byte + ocamlc.opt -verbose -ccopt -L/usr/lib/ -o misc -I /usr/lib/ocaml/3.09.2/pcap -ccopt -I/usr/lib/ocaml/3.09.2/pcap -ccopt -L/usr/lib/ocaml/3.09.2/pcap /usr/lib/ocaml/3.09.2/pcap/pcap.cma misc.cmo + gcc -Wl,-E -o 'misc' -I'/usr/lib/ocaml/3.09.2' -L/usr/lib/ -I/usr/lib/ocaml/3.09.2/pcap -L/usr/lib/ocaml/3.09.2/pcap /tmp/camlprimcb0920.c '-L/usr/lib/ocaml/3.09.2/pcap' '-L/usr/lib/ocaml/3.09.2' '-lpcap_stubs' '-lcallback' '-lpcap' '-lcamlidl' -lcamlrun -lm -ldl -lcurses -lpthread /usr/bin/ld: cannot find -lcallback collect2: ld returned 1 exit status Error while building custom runtime system ocamlc.opt returned with exit code 2 Any idea of what I'm doing wrong? Yours, david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Issue to build libmlpcap-ocaml-dev examples on Debian Etch
Hello, 2008/4/16 David MENTRE [EMAIL PROTECTED]: I'm trying to build /usr/share/doc/libmlpcap-ocaml-dev/examples/ on Debian Etch 4.0. It does not compile when doing a make: $ make [...] ocamlfind ocamlc -package pcap -linkpkg -o misc misc.cmo /usr/bin/ld: cannot find -lcallback collect2: ld returned 1 exit status Error while building custom runtime system make: *** [misc] Error 2 On my system, the only libcallback I have is /usr/lib/libcallback.so.0.0.0. [...] Any idea of what I'm doing wrong? Ok, found it! I needed to install libffcall1-dev package that contains the missing /usr/lib/libcallback.a library (many thanks to packages.debian.org ;-). Maybe libmlpcap-ocaml-dev should depend on libffcall1-dev? Is this a bug or expected behaviour? Yours, d. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Issue to build libmlpcap-ocaml-dev examples on Debian Etch
Hello, 2008/4/16 Sylvain Le Gall [EMAIL PROTECTED]: This is a bug. Could you submit a bug report? Done: Bug#476440. Yours, d. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Issue with font-lock-mode and ocaml-mode in Emacs?
Hello, I've just noticed that *under Ubuntu Gutsy* (yes, not a Debian release) the font-lock-mode of GNU Emacs is not properly initialised when using ocaml-mode. In need to add (require 'caml-font) in order to have correct colourisation. Before digging further, I would like to know if this issue is Ubuntu specific or exists (existed?) also in Debian. Ubuntu's package version of ocaml-mode in Gutsy is 3.09.2-9ubuntu1. For /usr/share/doc/ocaml-mode/changelog.Debian.gz, Ubuntu has not modified the package regarding the Emacs mode compared to the Original Debian's one: ocaml (3.09.2-9ubuntu1) gutsy; urgency=low * Build ocaml-native-compilers on lpia. * Set Ubuntu maintainer address. -- Matthias Klose [EMAIL PROTECTED] Tue, 07 Aug 2007 17:24:04 + ocaml (3.09.2-9) unstable; urgency=low * Add Replaces: ocaml-nox ( 3.09.2-8) to the ocaml package because of the ocamlbrowser move. * Sync debian/control.in with debian/control. -- Julien Cristau [EMAIL PROTECTED] Sun, 31 Dec 2006 01:45:53 +0100 [...] Yours, david -- GPG/PGP key: A3AD7A2A David MENTRE [EMAIL PROTECTED] 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Find corrupted bytecodes on Ubuntu (was: Re: How to know the set of (source?) packages having bytecode executables?)
Hello Stefano, Stefano Zacchiroli [EMAIL PROTECTED] writes: Nope, the file database AFAIK is not accessible via python-debian at the moment, nor it is from python-apt. For the sake of performances I suggest you to use apt-file instead of dpkg -S. Thank you for the apt-file suggestion, I did not know about it. In fact, identifying a corrupted OCaml bytecode is more complicated than I thought as the program can be launched and give some error messages vene if corrupted. So I basically installed all OCaml packages available, find the binaries available in a /bin directory (with the command attached) and launched them manually. Not very good engineering, I know. :-) I have made a first list of corrupted packages[1] and made a call on caml-list is case somebody would see another error. I have a question on the attached command: despite using 'apt-file -F', the command reports some packages like pkglist that does not seem to be OCaml related. Any idea why I observe such a behavior? Yours, d. Footnotes: [1] https://bugs.launchpad.net/ubuntu/+source/pkg-create-dbgsym/+bug/197293 -- GPG/PGP key: A3AD7A2A David MENTRE [EMAIL PROTECTED] 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A for i in list \ advi \ advi-examples \ approx \ ara-byte \ xara-gtk-byte \ bibtex2html \ libcairo-ocaml \ libcairo-ocaml-dev \ libcalendar-ocaml-dev \ cameleon \ cameleon-doc \ libcameleon-ocaml-dev \ camlidl \ libcamlimages-ocaml \ libcamlimages-ocaml-dev \ libcamlimages-ocaml-doc \ camlp5 \ libzip-ocaml \ libzip-ocaml-dev \ libcamomile-ocaml-data \ libcamomile-ocaml-dev \ cduce \ cmigrep \ confluence \ coq \ coq-libs \ coqide \ libcryptgps-ocaml-dev \ libcryptokit-ocaml \ libcryptokit-ocaml-dev \ dag2html \ edos-debcheck \ edos-rpmcheck \ libextlib-ocaml-dev \ libfacile-ocaml-dev \ felix \ ocaml-findlib \ freetennis \ freetennis-common \ libgdome2-xslt-dev \ libgdome2-xslt-ocaml \ libgdome2-xslt-ocaml-dev \ libgdome2-xslt0c2a \ geneweb \ gwsetup \ gwtp \ libgdome2-cpp-smart-dev \ libgdome2-cpp-smart0c2a \ libgdome2-ocaml \ libgdome2-ocaml-dev \ haxe \ headache \ hevea \ hlins \ liblablgl-ocaml \ liblablgl-ocaml-dev \ liblablgtk2-gl-ocaml \ liblablgtk2-gl-ocaml-dev \ liblablgtk2-gnome-ocaml \ liblablgtk2-gnome-ocaml-dev \ liblablgtk2-ocaml \ liblablgtk2-ocaml-dev \ liblablgtksourceview-ocaml \ liblablgtksourceview-ocaml-dev \ liblablgtk2-ocaml-doc \ liblablgtkmathview-ocaml \ liblablgtkmathview-ocaml-dev \ ledit \ liguidsoap \ liquidsoap \ matita \ matita-standard-library \ mediawiki \ mediawiki-math \ menhir \ mldonkey-gui \ mldonkey-server \ libgmp-ocaml \ libgmp-ocaml-dev \ libmlpcap-ocaml \ libmlpcap-ocaml-dev \ monotone-viz \ mtasc \ libmysql-ocaml \ libmysql-ocaml-dev \ libnumerix-ocaml \ libnumerix-ocaml-dev \ numerix-doc \ camlp4 \ camlp4-extra \ ocaml \ ocaml-base \ ocaml-base-nox \ ocaml-compiler-libs \ ocaml-interp \ ocaml-mode \ ocaml-native-compilers \ ocaml-nox \ ocaml-source \ libalsa-ocaml \ libalsa-ocaml-dev \ libao-ocaml \ libao-ocaml-dev \ libbenchmark-ocaml-dev \ libcurses-ocaml \ libcurses-ocaml-dev \ libdtools-ocaml-dev \ libexpat-ocaml \ libexpat-ocaml-dev \ libfileutils-ocaml-dev \ libgetopt-ocaml-dev \ libhttp-ocaml-dev \ libladspa-ocaml \ libladspa-ocaml-dev \ liblastfm-ocaml-dev \ libmad-ocaml \ libmad-ocaml-dev \ libogg-ocaml \ libogg-ocaml-dev \ libportaudio-ocaml \ libportaudio-ocaml-dev \ libreins-ocaml-dev \ libsha-ocaml \ libsha-ocaml-dev \ libshout-ocaml \ libshout-ocaml-dev \ libsoundtouch-ocaml \ libsoundtouch-ocaml-dev \ libsqlite3-ocaml \ libsqlite3-ocaml-dev \ libssl-ocaml \ libssl-ocaml-dev \ libyaml-syck-ocaml \ libyaml-syck-ocaml-dev \ libvorbis-ocaml \ libvorbis-ocaml-dev \ libxmlplaylist-ocaml-dev \ libagrep-ocaml \ libagrep-ocaml-dev \ libcreal-ocaml-dev \ libldap-ocaml-dev \ ocamldsort \ libocamlgraph-ocaml-dev \ libocamlgsl-ocaml \ libocamlgsl-ocaml-dev \ libequeue-gtk2-ocaml-dev \ libequeue-ocaml \ libequeue-ocaml-dev \ libnetclient-ocaml-dev \ libnethttpd-ocaml-dev \ libocamlnet-gtk2-ocaml-dev \ libocamlnet-ocaml \ libocamlnet-ocaml-bin \ libocamlnet-ocaml-dev \ libocamlnet-ocaml-doc \ libocamlnet-ssl-ocaml \ libocamlnet-ssl-ocaml-dev \ librpc-ocaml-dev \ libocamlodbc-ocaml-dev \ libsdl-ocaml \ libsdl-ocaml-dev \ ocamlwc \ ocamlweb \ ocsigen \ ocsigen-doc \ libcurl-ocaml \ libcurl-ocaml-dev \ omake
Re: How to know the set of (source?) packages having bytecode executables?
Hello Stefano, Stefano Zacchiroli [EMAIL PROTECTED] writes: [ me ] section that broke the binary. This bug should soon be fixed (https://bugs.launchpad.net/ubuntu/+source/ocamlnet/+bug/180364). In fact, the bug is not fixed yet. :-( After that, one will need to rebuild all OCaml packages having bytecode executables. Thus my question: is there a script somewhere that could help me list all packages (I suppose I mean source packages, right?) having bytecode executables, like ocamlnet for ocamlrpcgen binary? Short answer: we don't have anything like that that I'm aware of. Ok, thank you for your detailed answer. I'll think I'll try a more brute-force approach: installing all OCaml-related packages and look for OCaml bytecode binaries in /usr/bin/ (using the same pattern as proposed in the Ubuntu bug report). Is there a list of OCaml *binary* packages somewhere? From my search, this is not the case. After looking at Stephane's gen-binNMU-request.py script, using rmadison I should be able to make such a script. Yours, d. -- GPG/PGP key: A3AD7A2A David MENTRE [EMAIL PROTECTED] 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to know the set of (source?) packages having bytecode executables?
Hello,
David MENTRE [EMAIL PROTECTED] writes:
I'll think I'll try a more brute-force approach: installing all
OCaml-related packages and look for OCaml bytecode binaries in /usr/bin/
(using the same pattern as proposed in the Ubuntu bug report).
[...]
After looking at Stephane's gen-binNMU-request.py script, using rmadison
I should be able to make such a script.
After using Stephane's script as template, I have my Python script to
list all binary packages. I have also some Python code to test if a
file is an OCaml bytecode (match Caml1999X[0-9][0-9][0-9] pattern at the
last 12 bytes of the file).
With dpkg -S, I should be able to find the relevant binary packages
that contain a bytecode. Is it possible to do the same as dpkg -S from
Python code using, I suppose, python-debian code?
Here are my scripts, if it can help others.
Yours,
d.
PS : The ubuntu-hardy-ocaml-bin-pkg.py is Ubuntu Hardy specific but it
should be easy to adapt it to various Debian/Ubuntu releases.
--
GPG/PGP key: A3AD7A2A David MENTRE [EMAIL PROTECTED]
5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A
#!/usr/bin/python
# -*- coding: utf-8 -*-
# Extracted from gen-binNMU-request.py:
# * download()
# Use of rmadison also extracted from this script. Thanks Stephane Glondu!
import sys, os, re
from commands import getoutput, getstatusoutput
from httplib import HTTPConnection
reference_arch = i386
madison_split_regexp = re.compile([ |,\n]+)
def download(site, file_path):
c = HTTPConnection(site)
c.request(GET, /%s % file_path)
r = c.getresponse().read()
c.close()
return r
def get_binary_packages(src_pkg):
if src_pkg == :
return []
rmadison_raw = getoutput(rmadison -u ubuntu -s hardy -S %s % src_pkg)
binary_packages = []
for line in filter(None, rmadison_raw.split(\n)):
splitted = madison_split_regexp.split(line.strip())
binary_package_name = splitted[0]
version = splitted[1]
available_archs = splitted[3:]
#print binary_package_name, version, available_archs
if all in available_archs:
binary_packages.append(binary_package_name)
elif reference_arch in available_archs:
binary_packages.append(binary_package_name)
#print Kept: , binary_packages
return binary_packages
def output_aptget_command(package_list):
print ## To install ##
print apt-get \\
for pkg in package_list[:-1]:
print, pkg, \\
print, package_list[-1]
def main():
ocaml_sources_packages = download(pkg-ocaml-maint.alioth.debian.org,
ocaml_src_pkgs.txt).split(\n)
all_binary_packages = []
for src_pkg in ocaml_sources_packages:
all_binary_packages.extend(get_binary_packages(src_pkg))
output_aptget_command(all_binary_packages)
main()
#!/usr/bin/python
import sys
import os
import re
def is_ocaml_bytecode(filename):
f = open(filename, r)
f.seek(-12, 2) # go to 12 bytes before the end of file
bytes = f.read(12)
f.close()
if re.match('Caml1999X[0-9][0-9][0-9]', bytes):
return True
else:
return False
for filename in sys.argv[1:]:
print filename, is_ocaml_bytecode(filename)
How to know the set of (source?) packages having bytecode executables?
Hello, I few weeks ago, I asked about a bug on Ubuntu where an ocaml bytecode executable was not working. In fact, it was the addition of an ELF section that broke the binary. This bug should soon be fixed (https://bugs.launchpad.net/ubuntu/+source/ocamlnet/+bug/180364). After that, one will need to rebuild all OCaml packages having bytecode executables. Thus my question: is there a script somewhere that could help me list all packages (I suppose I mean source packages, right?) having bytecode executables, like ocamlnet for ocamlrpcgen binary? With such a script, I could inform the Ubuntu developer of needed rebuilds. Many thanks in advance, Sincerely yours, david -- 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...
Hello, Sven Luther [EMAIL PROTECTED] writes: 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. +1 As a simple user, it is always cumbersome to look for and install a new package only for a few files. Yours, d. -- GPG/PGP key: A3AD7A2A David MENTRE [EMAIL PROTECTED] 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Demexp-dev] Re: ocamlrpcgen no longer recognises command line options
Hello, Some progress has been made. 2008/1/6, David MENTRE [EMAIL PROTECTED]: So maybe the strip is done at another level or is the side effect of another system-wide change, but this is beyond my knowledge of Ubuntu and Debian. In any case, I'll add this information to the Ubuntu bug report[1]. [...] [1] https://bugs.launchpad.net/ubuntu/+source/ocamlnet/+bug/180364 It appears that adding .gnu_debuglink ELF section breaks the bytecode binaries. Martin Pitt is looking for a reliable way to identify ocaml bytecode programs so as to exclude them from the .gnu_debuglink ELF section addition process. He suggests objdump -x binary | grep -qw caml_release_bytecode and objdump -t binary. Any idea if this is the proper way? Sincerely yours, david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ocamlrpcgen no longer recognises command line options
Hello Stefano, [For context, this is a reply to: http://lists.debian.org/debian-ocaml-maint/2008/01/msg00061.html ] Stefano Zacchiroli [EMAIL PROTECTED] writes: Only the version number, not (necessarily) the package itself: Ubuntu rebuilds Debian packages in its universe and applies its own patches. [...] In case you want to forward a patch for this specific problem to the Ubuntu side, here is the needed line in debian/rules: DEB_STRIP_EXCLUDE += usr/bin/ocamlrpcgen (together with a similar line for usr/bin/netplex-admin, FWIF). Thank you for the explanations. I tried to find this Ubuntu's specific patch but found nothing. :-( I found no Ubuntu specific patch for ocamlnet or libocamlnet in: http://patches.ubuntu.com/o/ nor in: http://patches.ubuntu.com/libo/ Looking at http://packages.ubuntu.com/gutsy/libs/libocamlnet-ocaml it seems that the patch applied to the package is exactly the same as the Debian one (i.e. yours): http://archive.ubuntu.com/ubuntu/pool/universe/o/ocamlnet/ocamlnet_2.2.7-1.diff.gz It has the DEB_STRIP_EXCLUDE lines: +DEB_STRIP_EXCLUDE += usr/bin/netplex-admin# OCaml custom bytecode binaries can't be striped +DEB_STRIP_EXCLUDE += usr/bin/ocamlrpcgen So maybe the strip is done at another level or is the side effect of another system-wide change, but this is beyond my knowledge of Ubuntu and Debian. In any case, I'll add this information to the Ubuntu bug report[1]. Yours, d. Footnotes: [1] https://bugs.launchpad.net/ubuntu/+source/ocamlnet/+bug/180364 -- GPG/PGP key: A3AD7A2A David MENTRE [EMAIL PROTECTED] 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ocamlrpcgen no longer recognises command line options
Hello, I'm trying to compile my OCaml program under Ubuntu Gutsy. The program was compiling fine under Ubuntu Feisty. Apparently, ocamlrpcgen no longer recognises command line options: $ ocamlrpcgen -cpp none -int unboxed -hyper int64 -aux net/messages.xdr Unknown option -cpp. $ ocamlrpcgen -int unboxed -hyper int64 -aux net/messages.xdr Unknown option -int. $ ocamlrpcgen -hyper int64 -aux net/messages.xdrUnknown option -hyper. Unknown option -hyper. The Ubuntu Gutsy package is version 2.2.7, which is apparently the same as the Etch backport[1]. $ which ocamlrpcgen /usr/bin/ocamlrpcgen $ dpkg -S /usr/bin/ocamlrpcgen libocamlnet-ocaml-bin: /usr/bin/ocamlrpcgen $ apt-cache show libocamlnet-ocaml-bin [...] Version: 2.2.7-1 Any idea of the cause of this rather strange issue? How I might fix it? Is this issue common to all Debian based distribution or specific to Ubuntu Gutsy? Where should I report the bug? Many thanks in advance for any help, Yours, david Footnotes: [1] http://packages.debian.org/libocamlnet-ocaml etch-backports (libs): OCaml application-level Internet libraries - core runtime libraries 2.2.7-1~bpo40+1 [backports]: i386 -- GPG/PGP key: A3AD7A2A David MENTRE [EMAIL PROTECTED] 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ocamlrpcgen no longer recognises command line options
Hello Julien, Thank you for the quick answer. Julien Cristau [EMAIL PROTECTED] writes: Sounds like ocamlrpcgen has been stripped. Custom ocaml binaries can't be stripped, because of http://bugs.debian.org/256900 . I suggest you file a bug on the ubuntu bug tracker. Your diagnosis seems correct: $ ocamlrpcgen net/messages.xdr Fatal error: the file net/messages.xdr is not a bytecode executable file Apparently, the ocaml runtime in ocamlrpcgen is lacking some bytecode. I've filled a bug report: https://bugs.launchpad.net/ubuntu/+source/ocamlnet/+bug/180364 Any Ubuntu developer on debian-ocaml-maint? Yours, d. -- GPG/PGP key: A3AD7A2A David MENTRE [EMAIL PROTECTED] 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Demexp-dev] Re: camlgz, camlrpc, cduce for Ocaml 3.09
Hello, 2005/12/6, Thomas Petazzoni [EMAIL PROTECTED]: Maybe David Mentré (the demexp developer) will give his motivations behind the choice of camlgz instead of camlzip. camlgz provides in-memory zipping and unzipping while camlzip only provides zipping and unzipping from files. Yours, d.
Re: CDuce package
Thomas Petazzoni [EMAIL PROTECTED] writes: For the moment, the only thing I can say is that it needs the object files listed in ocamliface/Makefile (see http://www.cduce.org/c-bin/viewcvs.cgi/ocamliface/Makefile?rev=1.1content-type=text/vnd.viewcvs-markup) in the UTILS, PARSING and TYPING variables. Reading the same Makefile, I would reduce needed files of ocaml compiler to: UTILS=utils/misc.cmo utils/tbl.cmo utils/config.cmo \ utils/clflags.cmo utils/consistbl.cmo PARSING=parsing/longident.cmo TYPING=typing/ident.cmo typing/path.cmo \ typing/primitive.cmo typing/types.cmo \ typing/btype.cmo typing/oprint.cmo \ typing/subst.cmo typing/predef.cmo \ typing/datarepr.cmo typing/env.cmo \ typing/ctype.cmo typing/printtyp.cmo (both .cmo and .cmx files) The files parsing/asttypes.cmi and asttypes.ml seem also necessary. Yours, d. Personnal comment: why on earth such semantics for Makefiles. ;) -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE [EMAIL PROTECTED] 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDuce package
Thomas Petazzoni [EMAIL PROTECTED] writes: make[1]: Entering directory `/home/thomas/demexp/cduce-0.2.2/ocamliface' Build cmi2ml ocamlc -o cmi2ml -I debian/ocaml-3.08.2//utils -I debian/ocaml-3.08.2//parsing -I debian/ocaml-3.08.2//typing debian/ocaml-3.08.2//utils/misc.cmo debian/ocaml-3.08.2//utils/tbl.cmo [...] Unbound value Env.read_signature I took a look at typing/env.mli, and a read_signature function is defined in this module, so I don't see why ocamlc says that Env.read_signature is unbound. Any idea ? Try using an absolute path or relative path to /home/thomas/demexp/cduce-0.2.2/debian/ocaml-3.08.2/* (I suppose this is the correct path in your configuration. You are in /home/thomas/demexp/cduce-0.2.2/ocamliface when you compile ocaml objects and the relative path debian/ocaml-3.08.2//utils does not refer to any valid path. I hope I'm right. Yours, d. -- pub 1024D/A3AD7A2A 2004-10-03 David MENTRE [EMAIL PROTECTED] 5996 CC46 4612 9CA4 3562 D7AC 6C67 9E96 A3AD 7A2A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
