Bug#601297: #601297 - libcairo-ocaml-dev: Cannot compile programs due to outdated cairo-ocaml-dev
On 10/25/2010 12:33 PM, Evgeni Golov wrote: > Hi, > > this works for me. Could you provide an example that fails? > > I tried the following on Sid/amd64 and Squeeze/i386: > 1. apt-get install libcairo-ocaml-dev > 2. wget http://cgit.freedesktop.org/cairo-ocaml/plain/test/cube.ml > 3. ocamlopt -o cube -I /usr/lib/ocaml/cairo/ -I /usr/lib/ocaml/lablgtk2 > lablgtk.cmxa cairo.cmxa cairo_lablgtk.cmxa gtkInit.cmx cube.ml > 4. ./cube > > (3. is copied from test/Makefile of cairo-ocaml git) Ok, sorry, what actually fails is: % ocamlc -o cubec -I /usr/lib/ocaml/cairo/ -I /usr/lib/ocaml/lablgtk2 lablgtk.cma cairo.cma cairo_lablgtk.cma gtkInit.cmo cube.ml File "cube.ml", line 1, characters 0-1: Error: Error on dynamically loaded library: /usr/lib/ocaml/stublibs/dllmlcairo.so: /usr/lib/ocaml/stublibs/dllmlcairo.so: undefined symbol: caml_ba_byte_size -- 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/4cc55e2e.2010...@debian.org
Bug#601297: #601297 - libcairo-ocaml-dev: Cannot compile programs due to outdated cairo-ocaml-dev
Hi, this works for me. Could you provide an example that fails? I tried the following on Sid/amd64 and Squeeze/i386: 1. apt-get install libcairo-ocaml-dev 2. wget http://cgit.freedesktop.org/cairo-ocaml/plain/test/cube.ml 3. ocamlopt -o cube -I /usr/lib/ocaml/cairo/ -I /usr/lib/ocaml/lablgtk2 lablgtk.cmxa cairo.cmxa cairo_lablgtk.cmxa gtkInit.cmx cube.ml 4. ./cube (3. is copied from test/Makefile of cairo-ocaml git) Regards Evgeni -- 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/4cc55ceb.8060...@debian.org
Re: omake failures (#510919) (and RFS)
On Thu, 08 Jan 2009 02:05:02 +0100 Stéphane Glondu wrote: > Evgeni Golov a écrit : > > Did you also remove the binary from the .orig.tar.gz? We don't have the > > source for it... > > No, I didn't. Even though the source is not technically available (in > the archive, today), there is an advertised way to rebuild it with only > free tools... IMHO, it is not the same issue as all the recent firmware > fuss. Besides, we do not use this binary any more. For Lenny, it didn't > seem worth to me to repackage the upstream tarball. I'm not a good legal boy, but you're prolly correct that it can be in the source tarball for now. What do the others think? > BTW, there are many things that shouldn't be in the .orig.tar.gz (such > as CVS directories, for a start)... For future releases, it might be > relevant to repackage the upstream tarball. Yupp, but thats a different issue, not relevant here and now :) > > And for really closing 510919: could either ocaml-nox or omake provide > > a ocamldep-omake symlink, pointing to ocamldep? Just to make sure we > > (or actually you :P) don't break any user-scripts. > > This sounds like a dirty visible hack to me, I don't agree with this > proposal. Are there so many people hard-coding ocamldep-omake in their > scripts? Doesn't it sound reasonable to force people to update their > scripts now? Dunno if there are people hardcoding it, I don't do any ocaml stuff. But you should consider adding a debian/NEWS file, saying ocamldep-omake is gone now, so users notice this fact on upgrade and not when their stuff is failing. Regards Evgeni -- Bruce Schneier Fact Number 893: Schneier has no diseases, but he isn't vaccinated. Injection doesn't work with him. pgp7NO7l8su0I.pgp Description: PGP signature
Re: omake failures (#510919) (and RFS)
On Thu, 08 Jan 2009 01:29:49 +0100 Stéphane Glondu wrote: > As said in git commit bfd1cebf64a424759df083c1fc15276cc9ea3fff: > > Do not install ocamldep-omake (Closes: #510919) > > > > The build system of omake detects by itself that standard ocamldep > > supports -modules (starting from OCaml 3.10), and do not need > > ocamldep-omake in this case. However, it still installs it. Did you also remove the binary from the .orig.tar.gz? We don't have the source for it... And for really closing 510919: could either ocaml-nox or omake provide a ocamldep-omake symlink, pointing to ocamldep? Just to make sure we (or actually you :P) don't break any user-scripts. Regards Evgeni -- Bruce Schneier Fact Number 170: Bruce Schneier's abs are NP-hard. pgpbCVKcverq2.pgp Description: PGP signature
Re: omake failures (#510919)
Hey, please CC me, I'm not subscribed :) On Tue, 6 Jan 2009 23:21:22 +0200 George Danchev wrote: > 1. apply the above mentioned patch against ocamldep as brought with ocaml-nox > package. That would be pretty dangerous, since ocaml-nox rdeps are exposed at > risk. Unlikely to be approved by the release team. I bet it wont be approved, but building another binary out of the ocaml-nox source with the patch applied should work? So ocaml-nox will have ocamldep (the original) and ocamldep-omake (the patched). Or one could push the latter into a separate package built from the same source, would have to go through NEW then, but sounds more RM compatible than changing ocamldep directly. > 2. prepare a separate source package to carry out that special version of > ocamldep (possibly called ocamldep-omake) in order to avoid messing up with > ocaml-nox package, and make it build-dependency of omake. Possilbe drawbacks: > new package, unlikely to be approved by release team at that point. > > 3. extend the source package of omake in order to embed the sources of such a > special ocamldep-omake and invoke it right along during the omake build. > Drawbacks: embeded source copies, security risk. The separate source package would also have an embedded copy, same bad IMHO. > 4. completely remove that broken package from the archive, no build-repends > are found, no harm done. This is my favourity one. Well, omake is in Etch, and I dont like the idea to drop such a package. Additionally people could be using it localy, you newer know. > While I believe that 2nd. and 3rd. would have been possible (ugly, but > possible) courses of action before the freeze (provided these blatant > failures would have not been ignored lightly), I don't believe that release > team would approve them at that stage of the release. Obviosuly 1st. is > pretty dangerous, thus we will be better served with 4th. > > Comments ? I'd go for 1.5, ocaml-nox builds a new ocamldep-omake binary. But YMMV as usual :) Regards Evgeni -- Bruce Schneier Fact Number 955: Bruce Schneier does not get kidney stones. He gets Rosetta Stones. pgp3PBA7aHqIy.pgp Description: PGP signature
