Re: ocaml 3.08.3-3 built on all arches, and in the incoming dir, ready for level 2.
> If i did not miss any of those (Stefano, why does packages like ledit not show > up ?). Should geneweb be listed here (see Julien Cristau rmeark about Stefano graph missing some packages)? I follow all this very loosely and need to figure out whether I absolutely need to rebuild it or not (as far as I can see, this is not mandatory, is it?) I prefer rebuilding it only if necessary. The package is quiet for some time and rock solid so, well, I prefer focusing on more important stuff at this moment. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.08.3-3 built on all arches, and in the incoming dir, ready for level 2.
> If the package build-depends on ocaml, you will have to build it or it will > FTBFS, which is an RC bug. If you tell us the remaining build-dependencies > beyond just ocaml, i will tell you when you have to rebuild it, which should > be rather trivial. Build-Depends: debhelper (>= 4.1.16), ocaml-best-compilers, ocaml (>= 3.04), doc-base, dh-buildinfo, iso-codes, po-debconf, dpatch Sure, it is trivial to rebuild... As Julien mentioned, rebuilding it just to be sure is probably a good idea anyway. Hmm, well, looking at my changelog, I have a few pending l10n stuff and very minor so it's probably a good occasion to upload anyway. You made me change my mind...:-) /me launches debuild -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.08.3-3 built on all arches, and in the incoming dir, ready for level 2.
> As Julien mentioned, rebuilding it just to be sure is probably a good > idea anyway. > > Hmm, well, looking at my changelog, I have a few pending l10n stuff > and very minor so it's probably a good occasion to upload anyway. > > You made me change my mind...:-) > > /me launches debuild geneweb 4.10-5, built with ocaml-3.08.3 has been uploaded yesterday -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.08.3-3 built on all arches, and in the incoming dir, ready for level 2.
Quoting Christian Perrier ([EMAIL PROTECTED]): > geneweb 4.10-5, built with ocaml-3.08.3 has been uploaded yesterday And, bloody hell, I knew I should have done so. See #301378 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.08.3-3 built on all arches, and in the incoming dir, ready for level 2.
> As i read the patch provided by Daniel, i don't think that you need to have > 3.08.3 for this patch to build. I don't really understand your question I just wanted to double check that I don't need to update the Build-Depends of the fixed package. I finally managed to check this myself by temporarily trying to rebuild it with testing's ocaml (ie 3.08.2). So, as a conclusion, the patched package for geneweb has been uploaded and should reach unstable today. It was uploaded with priority medium to have enough time to it to be tested properly (advice from the release team) and to give me enough time to block it from testing as I'll be away the next 2 days. In short, everything is fine again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#309743: [intl:fr] ocaml-tools debconf templates translation
> #. Type: boolean > #. Description > #: ../ocaml-tools.templates:4 > msgid "Do you want to use omlet as default vim mode?" > msgstr "Faut-il utiliser omlet comme mode vim par défaut ?" > > #. Type: boolean > #. Description > #: ../ocaml-tools.templates:4 > msgid "" > "Omlet is an enhanced vim mode for OCaml which has better indentation than " > "the official vim mode for OCaml. You don't need this if you don't use vim." > msgstr "" > "Omlet est un mode vim étendu pour Ocaml qui permet une meilleure indentation > " > "que le mode vim officiel pour Ocaml. Vous n'avez pas besoin de cela si vous " > "n'utilisez pas vim." > > #. Type: boolean > #. Description > #: ../ocaml-tools.templates:4 > msgid "Do you want to use it as the default mode for editing ml files?" > msgstr "" > "Veuillez confirmer que vous souhaitez l'utiliser comme mode par défaut pour " > "l'édition de fichiers ml." By the way, to whoever is maintaining this package : repeating a question in both the long and short description of a debconf template is highly discouraged. Mor egenerally speaking, the interrogative form should be used ONLY for boolean templates and ONLY in the short part of the template. Indeed, here, the second paragraph of the template is absolutely useless. Long descriptions should NOT repeat what short descriptions already mention. For further description of these concepts, see debconf-devel(7) and the Developer's Reference. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problem with gramlib.cmxa
Hello folks, First of all, a very quick introduction : after being granted as Debian Developer, I am currently in the process of taking over the maintenance of the Debian package for Geneweb, Daniel de Rauglaudre's genealogy software. I already have contributed to former versions of the package, which was maintained by Brent Fulgham (who is, I guess, still subscribed to this list). Now to the problem which made me urgently subscribe to the list (I will re-subscribe with my home address, which is the one I use for my Debian activities when possible) : It looks like Geneweb compilation has been broken by the very recent update of the camlp4 package from 3.01.6 to 3.02 : ocamlopt.opt unix.cmxa `camlp4 -where`/gramlib.cmxa x1.cmxa x2.cmxa gwd.cmx -cclib -lunix -o gwd.opt Cannot find file /usr/lib/camlp4/gramlib.cmxa The /usr/lib/camlp4/gramlib.cmxa file, which was there in 3.01.6 is not there anymore. Unfortunately, I'm not really familiar with OCAML so that I cannot figure out... In the same time I post this, I try to contact Daniel for getting his word about this. -- Christian Perrier ONERA/Département Réseau et Informatique Scientifique +33 (0) 1 4673 4438 - +33 (0) 6 1016 9480 PGP/GnuPG Key ID 30C9348A (DSS)
Re: Problem with gramlib.cmxa
Quoting Christian Perrier ([EMAIL PROTECTED]): > The /usr/lib/camlp4/gramlib.cmxa file, which was there in 3.01.6 is not > there anymore. > > Unfortunately, I'm not really familiar with OCAML so that I cannot figure > out... > > In the same time I post this, I try to contact Daniel for getting his word > about this. After a few mails with Daniel (who is also camlp4 author) it looks like the bug lies in the camlp4 package. "make opt" should be done on platforms where an optimised OCAML exist I attach the appropriate patch for the rules file of the camlp4 package. It just uncomments a line in build-stamp...:-) With this patch, I have been able to compile a package with the cmxa file I need -- Christian Perrier ONERA/Département Réseau et Informatique Scientifique +33 (0) 1 4673 4438 - +33 (0) 6 1016 9480 PGP/GnuPG Key ID 30C9348A (DSS) *** rules.old Wed Aug 22 16:48:23 2001 --- rules Wed Aug 22 16:42:09 2001 *** *** 18,24 # if [ ! -f /usr/bin/ocamlc.opt ] ; then sed -e 's/OCAMLC=ocamlc.opt/OCAMLC=ocamlc/' -e 's/OCAMLOPT=ocamlopt.opt/OCAMLOPT=ocamlopt/' config/Makefile > config/Makefile.new ; mv config/Makefile.new config/Makefile ; fi ./configure $(MAKE) world ! # if [ -f /usr/bin/ocamlopt ] ; then $(MAKE) opt ; fi touch build-stamp --- 18,24 # if [ ! -f /usr/bin/ocamlc.opt ] ; then sed -e 's/OCAMLC=ocamlc.opt/OCAMLC=ocamlc/' -e 's/OCAMLOPT=ocamlopt.opt/OCAMLOPT=ocamlopt/' config/Makefile > config/Makefile.new ; mv config/Makefile.new config/Makefile ; fi ./configure $(MAKE) world !if [ -f /usr/bin/ocamlopt ] ; then $(MAKE) opt ; fi touch build-stamp
Re: Problem with gramlib.cmxa
Sven disait : > mmm, will this package also build correctly on architecture that don't compile I guess yes. > thenative code compiler, like m68K ? If not, this is a serious or even release > critical bug which will promptly be submitted against your package by the > corresponding auto builders. > > That said, it is normally just necessary to check for the existance of the > ocamlopt compiler, like it is done in other existing packages, mlgtk having > been the first where i implemented this. I suppose you did it already so, not > having seen the patch, but wanted to write this just to make sure you did. The patch just activates the test. It uncomments the last of these lines to debian.rules : ./configure $(MAKE) world if [ -f /usr/bin/ocamlopt ] ; then $(MAKE) opt ; fi (the if line was already there, but commented) If ocamlopt is found, then "make opt", otherwise do only the "make world". Looks to me like it will compile on m68k... I'm waiting for news from Fernando Sanchez. I thought he would answer quickly in the list, so that I don't have to open a bugbut I guess I will do so, just in case. As the new package breaks the compilation of other packages, what is the correct severity of the bug, in your opinion? -- Christian Perrier DRIS/SRL Châtillon A-9f05 (01467)34438 - 06 1016 9480 PGP/GnuPG Key ID 30C9348A (DSS)
Re: ocaml 3.04-5 in incoming ...
Quoting Sven ([EMAIL PROTECTED]): > Changes: > ocaml (3.04-5) unstable; urgency=low > . >* Split ocamlc.opt, ocamlopt.opt and ocamllex.opt into the > ocaml-native-compilers package. >* The ocaml-best-compilers virtual package is provided by > ocaml-native-compilers if it is built and by ocaml if not. >* Added an ocaml-source package containing the source to ocaml for packages > which need them as build-depends. >* Applied Ian Zimmerman's caml.el patch. (Closes:#129650,#130301) I have followed the discussion about this problem from time to time. Are my conclusions OK : I should modify the Build-Depends of my package from ocaml to ocaml-best-compilers, am I wrong? Then, if the optimised compiler exist for the platform the package is built on, it will be used (my rules files already handles this) and the normal compiler will be used if the optimised one does not exist.
Re: ocaml 3.04-5 in incoming ...
Quoting Sven ([EMAIL PROTECTED]): > Well, what packages do you maintain, are they very big sources, like coq, > where there is a sensible difference, or smaller stuff, where there is no > noticeable difference. geneweb is by far not small stuff.:-) Daniel de Rauglaudre, upstream author, explicitely recommends the compilation with optimised compilers whan available...
Re: ocaml 3.04-5 in incoming ...
Quoting Sven ([EMAIL PROTECTED]): > Notice that, i think, you still would have to depend on ocaml, altough it may > not be necessary, because ocaml-native-compilers depends on ocaml. > > Also, your build depend on ocaml-best-compilers cannot be a versioned > dependency. H. So, yes, I will have to Build-Depends on both ocaml-best-compilers so that the most appropriate compiler is used...but also on ocaml so that I can version the Build-Depends (geneweb needs 3.04). At this time, the most appropriate seems to be : Build-Depends: ocaml (>=3.04), ocaml-best-compilers
Re: ocaml 3.04-9 uploaded
Quoting Sven ([EMAIL PROTECTED]): > Hope this will be the right on now, i think no serious bugs are still there, > and that this could be a woody release candidate. Thanks for this as, due to it entering testing, I finally got "my" geneweb 4.04-1 also entering testing. Now waiting for the very latest version of geneweb (which is Build-Depending on ocaml-best-compilers...thus, I guess, waiting for it to enter testing) to go into testing. Sven (or others), if you have a little bit of time remaining, may you check to Depends and Build-Depends of geneweb? I have tried to follow this list so that I don't make mistakes and use the appropriate dependencies, but I have some doubts...:-) Build-Depends includes at this time : ocaml-best-compilers, ocaml (>=3.04) Those who find inconsistencies, be kind enough for opening a bug, of course. As I will lack a bit of time in the next weeks, I want to prepare a good release geneweb package
Re: ocaml 3.06 + mlgtk + lablgl
Quoting Sven LUTHER ([EMAIL PROTECTED]): > Hello, ... > > I am just uploading ocaml 3.06-1 to ftp-master's incoming. And geneweb 4.07-1 followed by a few hours (I was waiting for ocaml 3.06 as broken 3.05 wasn't suitable for build as advertised here by Jérome, thakns Jérome). > to put there, i lost my mail archive), and 8 is about a new, cleaner way > of doing dependencies for libraries. (no more ocaml (>=3.06-1), ocaml > (<<3.07-1), but simply ocaml-3.06). Well, at this time, in geneweb, I have : Suggests: ocaml (>= 3.04), menu (>= 1.5), gwtp I don't really know why I added this Suggestion on ocaml:-). I'll investigate and will probably remove it (geneweb can run without ocaml, of course). But I also have a "Build-Depends: debhelper, ocaml-best-compilers, ocaml (>= 3.04), doc-base" line. Why this line? First of course for properly getting either the native or the bytecode compiler, depending on their availibility on a given architecturebut ALSO because upstream developer (namely Daniel de Rauglaudre) mentions that ocaml 3.04 is *required* and sufficient (for what I have tested until now) for this version of Geneweb. If I replace my "ocaml (>=3.04)" statement by "ocaml-3.06" (or whichever further version), I will make package builds more restrictive without any real reason. For instance, the unofficial woody backports which I maintain for Daniel's FTP site will require a small useless change to debian/control... So, in my opinion at least, there are reasons for still carrying old way dependencies rather than the one suggested by ocaml_packaging_policyand this is why I keep my Build dependencies as such...at least as long as someone convinces me that I am wrong..:-)
Re: ocaml 3.06 + mlgtk + lablgl
> > I don't really know why I added this Suggestion on ocaml:-). I'll > > investigate and will probably remove it (geneweb can run without ocaml, of > > course). > > Please do ... This will be done in next release of the package. > Notice how it speak only about _library_ packages, not about application > packages, as it did as well in the older packaging policy, altough it > may have been less clear. > > So, again, people don't really read what i write, maybe i am not clear > enough, should i be insisting more heavily on the fact that it only > concerns libraries and not apps here ? Well, probably as at least one (myself...:-)) missed the point. Maybe writing the word "library" uppercase would help us, stupid people..:-)
Re: Hi, packaging mldonkey, rpath + other questions
Quoting Sven LUTHER ([EMAIL PROTECTED]): > > 2. mldonkey uses ocamlopt.opt but ocamlopt works as well. Which of the > > two should I use? Should I build-depend on eigther or conflict with > > one? > > You should build depend on ocaml-best-compilers, and do a test for the > presence of ocamlopt.opt before using it. Besides Stefano and Sven advices, I may add that such a test for presence of ocamlopt.opt may be found in other ocaml-bases packages... For instance, in "my" own package (geneweb, genealogical software written in ocaml), I deal with this as follows : upstream Geneweb includes a file named "tools/Makefile.inc" in all Makefile files. Upstream suggest putting the appropriate lines depending on the presence of "opt" compilers : OCAMLC=ocamlc.opt OCAMLOPT=ocamlopt.opt or OCAMLC=ocamlc OCAMLOPT=ocamlopt From the original Makefile.inc file, I make two files, one with "opt" lines and the other without. Then, I added this in debian/rules (stolen from the list or another package!): WAY=$(shell if [ -f "/usr/bin/ocamlc.opt" ]; then echo "opt"; \ else echo "out";\ fi) # Move the proper makefile into place cp -f `pwd`/tools/Makefile.inc.$(WAY) `pwd`/tools/Makefile.inc $(MAKE) $(WAY) IMHO, this allows minimal modification of original sourcesand it properly deals with the presence/lack of optimised compilers. I could also "edit" Makefile.inc on the fly... Of course, my package Build-Depends on ocaml-best-compilers as it was previously written... All this works well, though I'm not really an ocaml specialist (I'm far more a genealogist...:-)) pgpMjNaLpcVa6.pgp Description: PGP signature
Re: planets entered the archives.
Quoting Ralf Treinen ([EMAIL PROTECTED]): > The debian-ocaml-maint list is subscribed in the package tracking > system to all packages written in ocaml. Then it should maybe be subscribed to geneweb's PTS, no ?
Re: planets entered the archives.
Quoting Stefano Zacchiroli ([EMAIL PROTECTED]): > Well the original idea was to subscribe to the PTS for knowing how to > deal with needed rebuilds of libraries, incompatibilities with newer > versions of the ocaml compiler/runtime and similar problems. > > Geneweb is built as native code executable and thus have no runtime > problem, this is the reason why was not initially subscribed, the same > applies for other packages like coq and unison for example: > debian-ocaml-maint is not subscribed to their PTS. OK. Got the point. For sure, having the list subscribed to geneweb's PTS wouldn't be useful at all...and would probably bother people when I update the package because I play with debconf translation or polish the whole thing for the hypothetical sarge release... :-) About unison : I didn't even know this is an ocaml application though I use it daily.. :-)
Re: ocaml 3.07beta2 is up at people.debian.org/~luther/ocaml
Quoting Sven Luther ([EMAIL PROTECTED]):
> W: ocaml source: newer-standards-version 3.6.0
lintian needs update. BTW, you can now use 3.6.1 as long as you use
debconf for user input during package installation.
> W: ocaml source: outdated-autotools-helper-file config/gnu/config.guess
> 2001-06-25
> W: ocaml source: outdated-autotools-helper-file config/gnu/config.sub
> 2001-06-08
Maybe you can consider using in debian/rules a system for
automagically replace upstream-provided config.{guess|sub} files by
more up-to-date ones which come with autotools-dev.
See /usr/share/doc/autotools-dev README's for examples.Or one of
my packages (lifelines or poedit).
Sorry if you're aware of all this so that I try to learn you something
you better know than me...which is perfectly possible... :-)
Re: ocaml 3.07beta2 is up at people.debian.org/~luther/ocaml
Quoting Sven Luther ([EMAIL PROTECTED]):
> > > W: ocaml source: newer-standards-version 3.6.0
> >
> > lintian needs update. BTW, you can now use 3.6.1 as long as you use
> > debconf for user input during package installation.
>
> I don't do any user input thingy anymore, so i guess it is ok, wheter i
> use debconf or not.
It is. The "should" about debconf use for user input is the only non
trivial thing that changed.
>
> > > W: ocaml source: outdated-autotools-helper-file config/gnu/config.guess
> > > 2001-06-25
> > > W: ocaml source: outdated-autotools-helper-file config/gnu/config.sub
> > > 2001-06-08
> >
> > Maybe you can consider using in debian/rules a system for
> > automagically replace upstream-provided config.{guess|sub} files by
> > more up-to-date ones which come with autotools-dev.
>
> I don't like this, it messes up the .diff.gz file with lot of useless
> config* stuff. What is the best way to handling this ?
Having upstream update their files more often, maybe .. :-)
As far as I have understood, having up-to-date files is important for
porting issues, mostly on exotic architectures. I learned about this
when I got FTBFS'ed because one of my package did not build anymore on
ARM, IA64 or whatever.
geneweb and ocaml 3.07 : help.. :-)
Well, as some of you may know, I'm not an ocaml expert...I'm even not a coding expert, by the way. I maintain the geneweb package because it's part of my hobby, mostly. Also because I think I can make good work with it as long as it does not invlove digging in the dirt^W code. So I'm needing some Ocaml competences for helping me. With ocaml 3.07 release, the geneweb package does not compile from sources anymore. This is probably trivial, but I cannot handle this by myself. Here are the symptoms : camlp4r pa_ifdef.cmo -DUNIX -o wserver.ppi wserver.mli ocamlc.opt -warn-error A -I `camlp4 -where` -c -intf wserver.ppi File "wserver.mli", line 24, characters 15-46: The type constructor format expects 3 argument(s), but is here applied to 4 argument(s) make[2]: *** [wserver.cmi] Erreur 2 And the offending code : ifdef OCAML_307 then value wprint : format 'a out_channel unit unit -> 'a else value wprint : format 'a out_channel unit -> 'a; (* To be called to print page contents. *) (you will notice the possible OCAML_307 define) I tried to compile with -DOCAML_307 but the same happens. Probably because the define is implicit when camlp4r is the 3.07 version. The only way to get through this is by commenting stuff : (* ifdef OCAML_307 then value wprint : format 'a out_channel unit unit -> 'a else *) value wprint : format 'a out_channel unit -> 'a; (* To be called to print page contents. *) But this is probably silly.. :-) I could ask Daniel de Rauglaudre, upstream author, but I prefer asking here first as Daniel is currently very busy and I'd prefer trying this as a last option I would probably need an ocaml expert as co-maintainer for geneweb... :-)
Re: geneweb and ocaml 3.0 7 : help.. :-)
Quoting Sven Luther ([EMAIL PROTECTED]): > On Fri, Oct 03, 2003 at 08:00:56PM +0200, Remi Vanicat wrote: > > > I could ask Daniel de Rauglaudre, upstream author, but I prefer asking > > > here first as Daniel is currently very busy and I'd prefer trying this > > > as a last option > > > > you should tell upstream that is code does not compile, it may not be > > aware of it. > > Well, he may not care though, as if i am not wrong, he left the ocaml > team on quite bad terms over calmp4. He certainly cares anyway as geneweb is his baby and related to one of his hobbies Thanks for your advice, I'll try removing the OCAML_307 stuff.
Re: geneweb and ocaml 3.0 7 : help.. :-)
> Thanks for your advice, I'll try removing the OCAML_307 stuff. Fine. All compiled well and the new geneweb will be on its way to unstable very soon.
Latest geneweb package now in testing
Thanks to all the great work of core ocaml package maintainers, the latest (and probably final, except for including new debconf translations in some exotic languages) geneweb package has reached the Grail : it is now in testing... :-) Congrats, folks, you made the transition simple and easy and properly helped me to sort out the minor compilation problems I had with the new 3.07 ocaml. À la vôtre... :-) --
Re: D-I translations: tasksel (Denis Barbier mail to -i18n)
Quoting Jérôme Marant ([EMAIL PROTECTED]): > I think that free programs shall not refer to non-free ones. Thou Shall not refer to non-free programs Thou Shall not promote non-free Non-free is Evil Amen :-)
Re: D-I translations: tasksel (Denis Barbier mail to -i18n)
> How funny. Well, I prefer this over saying you that I think your reasoning is a kind of bigotry, because I certainly don't want to be offensive to people I consider great contributors to the free software community. Apologies if I indeed sounded offensive. This was just a way of exrepssing my opinion on this topic.
Ocaml gettext library?
The geneweb package currently uses its own system for handling its internal translation. I started thinking about asking Daniel de Rauglaudre for using a standard gettext format for i18n. I guess that some standardized ocaml library exists for this. Am I wrong ? I'm not competent enough for implementing this myself and I'm not sure Daniel would be enthusiast for doing this himself, so any help may be welcome. --
Re: Ocaml gettext library?
Quoting Remi Vanicat ([EMAIL PROTECTED]): > > I guess that some standardized ocaml library exists for this. Am I > > wrong ? > > I know no standardized ocaml library for this. Hmmm. Interesting project if someone is looking for something to code in ocaml:-) I'm absolutely incompetent for thisso let's wait until someone interested AND competent can start such work.
Re: splitting up the ocaml package: summary
> Humm... the split is fine with me, but i just don't like name : > pkgdepends contents > - > ocaml everythingeverything > ocaml-base ocaml-interpreter > ocaml-interpreter > ocaml-compilers (pseudo package) > ocaml-native-compilers compilers *.opt > ocaml-byte-compilers compilers *.byte > liblabltk-ocaml labltk stublibs > liblabltk-ocaml-dev liblabltk-ocaml labltk header > libbase-extra-ocaml extra stublibs > libbase-extra-ocaml-dev libbase-extra-ocaml extra header > libgraphics-ocamlgraphics stublibs > libgraphics-ocaml-devgraphics header I have had a look to my geneweb package. Currently, its dependencccies are: Build-Depends: .../... ocaml-best-compilers, ocaml (>= 3.04), .../... I'm not sure to remember why both are required, by the wayanyway, this currently works by making it use the native compiler on platforms which have one and the byte compiler otherwise My understanding of the above scheme is that I should now use only "ocaml-compilers" which is a pseudo-package for "native" or "byte" depending oin the platform. Am I right? I suppose of course that I need waiting for these to be uploaded in unstable and built on all arches for uploading a modified geneweb. Maybe waiting for the transition packages to reach testing is even better as I will be sure that geneweb entering testing will not be stucked by some weird thing preventing the ocal packages to enter testing.
Problem with gramlib.cmxa
Hello folks, First of all, a very quick introduction : after being granted as Debian Developer, I am currently in the process of taking over the maintenance of the Debian package for Geneweb, Daniel de Rauglaudre's genealogy software. I already have contributed to former versions of the package, which was maintained by Brent Fulgham (who is, I guess, still subscribed to this list). Now to the problem which made me urgently subscribe to the list (I will re-subscribe with my home address, which is the one I use for my Debian activities when possible) : It looks like Geneweb compilation has been broken by the very recent update of the camlp4 package from 3.01.6 to 3.02 : ocamlopt.opt unix.cmxa `camlp4 -where`/gramlib.cmxa x1.cmxa x2.cmxa gwd.cmx -cclib -lunix -o gwd.opt Cannot find file /usr/lib/camlp4/gramlib.cmxa The /usr/lib/camlp4/gramlib.cmxa file, which was there in 3.01.6 is not there anymore. Unfortunately, I'm not really familiar with OCAML so that I cannot figure out... In the same time I post this, I try to contact Daniel for getting his word about this. -- Christian Perrier ONERA/Département Réseau et Informatique Scientifique +33 (0) 1 4673 4438 - +33 (0) 6 1016 9480 PGP/GnuPG Key ID 30C9348A (DSS) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with gramlib.cmxa
Quoting Christian Perrier ([EMAIL PROTECTED]): > The /usr/lib/camlp4/gramlib.cmxa file, which was there in 3.01.6 is not > there anymore. > > Unfortunately, I'm not really familiar with OCAML so that I cannot figure > out... > > In the same time I post this, I try to contact Daniel for getting his word > about this. After a few mails with Daniel (who is also camlp4 author) it looks like the bug lies in the camlp4 package. "make opt" should be done on platforms where an optimised OCAML exist I attach the appropriate patch for the rules file of the camlp4 package. It just uncomments a line in build-stamp...:-) With this patch, I have been able to compile a package with the cmxa file I need -- Christian Perrier ONERA/Département Réseau et Informatique Scientifique +33 (0) 1 4673 4438 - +33 (0) 6 1016 9480 PGP/GnuPG Key ID 30C9348A (DSS) *** rules.old Wed Aug 22 16:48:23 2001 --- rules Wed Aug 22 16:42:09 2001 *** *** 18,24 # if [ ! -f /usr/bin/ocamlc.opt ] ; then sed -e 's/OCAMLC=ocamlc.opt/OCAMLC=ocamlc/' -e 's/OCAMLOPT=ocamlopt.opt/OCAMLOPT=ocamlopt/' config/Makefile > config/Makefile.new ; mv config/Makefile.new config/Makefile ; fi ./configure $(MAKE) world ! # if [ -f /usr/bin/ocamlopt ] ; then $(MAKE) opt ; fi touch build-stamp --- 18,24 # if [ ! -f /usr/bin/ocamlc.opt ] ; then sed -e 's/OCAMLC=ocamlc.opt/OCAMLC=ocamlc/' -e 's/OCAMLOPT=ocamlopt.opt/OCAMLOPT=ocamlopt/' config/Makefile > config/Makefile.new ; mv config/Makefile.new config/Makefile ; fi ./configure $(MAKE) world !if [ -f /usr/bin/ocamlopt ] ; then $(MAKE) opt ; fi touch build-stamp
Re: Problem with gramlib.cmxa
Sven disait : > mmm, will this package also build correctly on architecture that don't compile I guess yes. > thenative code compiler, like m68K ? If not, this is a serious or even release > critical bug which will promptly be submitted against your package by the > corresponding auto builders. > > That said, it is normally just necessary to check for the existance of the > ocamlopt compiler, like it is done in other existing packages, mlgtk having > been the first where i implemented this. I suppose you did it already so, not > having seen the patch, but wanted to write this just to make sure you did. The patch just activates the test. It uncomments the last of these lines to debian.rules : ./configure $(MAKE) world if [ -f /usr/bin/ocamlopt ] ; then $(MAKE) opt ; fi (the if line was already there, but commented) If ocamlopt is found, then "make opt", otherwise do only the "make world". Looks to me like it will compile on m68k... I'm waiting for news from Fernando Sanchez. I thought he would answer quickly in the list, so that I don't have to open a bugbut I guess I will do so, just in case. As the new package breaks the compilation of other packages, what is the correct severity of the bug, in your opinion? -- Christian Perrier DRIS/SRL Châtillon A-9f05 (01467)34438 - 06 1016 9480 PGP/GnuPG Key ID 30C9348A (DSS) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.04-5 in incoming ...
Quoting Sven ([EMAIL PROTECTED]): > Changes: > ocaml (3.04-5) unstable; urgency=low > . >* Split ocamlc.opt, ocamlopt.opt and ocamllex.opt into the > ocaml-native-compilers package. >* The ocaml-best-compilers virtual package is provided by > ocaml-native-compilers if it is built and by ocaml if not. >* Added an ocaml-source package containing the source to ocaml for packages > which need them as build-depends. >* Applied Ian Zimmerman's caml.el patch. (Closes:#129650,#130301) I have followed the discussion about this problem from time to time. Are my conclusions OK : I should modify the Build-Depends of my package from ocaml to ocaml-best-compilers, am I wrong? Then, if the optimised compiler exist for the platform the package is built on, it will be used (my rules files already handles this) and the normal compiler will be used if the optimised one does not exist. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.04-5 in incoming ...
Quoting Sven ([EMAIL PROTECTED]): > Well, what packages do you maintain, are they very big sources, like coq, > where there is a sensible difference, or smaller stuff, where there is no > noticeable difference. geneweb is by far not small stuff.:-) Daniel de Rauglaudre, upstream author, explicitely recommends the compilation with optimised compilers whan available... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.04-5 in incoming ...
Quoting Sven ([EMAIL PROTECTED]): > Notice that, i think, you still would have to depend on ocaml, altough it may > not be necessary, because ocaml-native-compilers depends on ocaml. > > Also, your build depend on ocaml-best-compilers cannot be a versioned > dependency. H. So, yes, I will have to Build-Depends on both ocaml-best-compilers so that the most appropriate compiler is used...but also on ocaml so that I can version the Build-Depends (geneweb needs 3.04). At this time, the most appropriate seems to be : Build-Depends: ocaml (>=3.04), ocaml-best-compilers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.04-9 uploaded
Quoting Sven ([EMAIL PROTECTED]): > Hope this will be the right on now, i think no serious bugs are still there, > and that this could be a woody release candidate. Thanks for this as, due to it entering testing, I finally got "my" geneweb 4.04-1 also entering testing. Now waiting for the very latest version of geneweb (which is Build-Depending on ocaml-best-compilers...thus, I guess, waiting for it to enter testing) to go into testing. Sven (or others), if you have a little bit of time remaining, may you check to Depends and Build-Depends of geneweb? I have tried to follow this list so that I don't make mistakes and use the appropriate dependencies, but I have some doubts...:-) Build-Depends includes at this time : ocaml-best-compilers, ocaml (>=3.04) Those who find inconsistencies, be kind enough for opening a bug, of course. As I will lack a bit of time in the next weeks, I want to prepare a good release geneweb package -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.06 + mlgtk + lablgl
> > I don't really know why I added this Suggestion on ocaml:-). I'll > > investigate and will probably remove it (geneweb can run without ocaml, of > > course). > > Please do ... This will be done in next release of the package. > Notice how it speak only about _library_ packages, not about application > packages, as it did as well in the older packaging policy, altough it > may have been less clear. > > So, again, people don't really read what i write, maybe i am not clear > enough, should i be insisting more heavily on the fact that it only > concerns libraries and not apps here ? Well, probably as at least one (myself...:-)) missed the point. Maybe writing the word "library" uppercase would help us, stupid people..:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hi, packaging mldonkey, rpath + other questions
Quoting Sven LUTHER ([EMAIL PROTECTED]): > > 2. mldonkey uses ocamlopt.opt but ocamlopt works as well. Which of the > > two should I use? Should I build-depend on eigther or conflict with > > one? > > You should build depend on ocaml-best-compilers, and do a test for the > presence of ocamlopt.opt before using it. Besides Stefano and Sven advices, I may add that such a test for presence of ocamlopt.opt may be found in other ocaml-bases packages... For instance, in "my" own package (geneweb, genealogical software written in ocaml), I deal with this as follows : upstream Geneweb includes a file named "tools/Makefile.inc" in all Makefile files. Upstream suggest putting the appropriate lines depending on the presence of "opt" compilers : OCAMLC=ocamlc.opt OCAMLOPT=ocamlopt.opt or OCAMLC=ocamlc OCAMLOPT=ocamlopt From the original Makefile.inc file, I make two files, one with "opt" lines and the other without. Then, I added this in debian/rules (stolen from the list or another package!): WAY=$(shell if [ -f "/usr/bin/ocamlc.opt" ]; then echo "opt"; \ else echo "out";\ fi) # Move the proper makefile into place cp -f `pwd`/tools/Makefile.inc.$(WAY) `pwd`/tools/Makefile.inc $(MAKE) $(WAY) IMHO, this allows minimal modification of original sourcesand it properly deals with the presence/lack of optimised compilers. I could also "edit" Makefile.inc on the fly... Of course, my package Build-Depends on ocaml-best-compilers as it was previously written... All this works well, though I'm not really an ocaml specialist (I'm far more a genealogist...:-)) msg01737/pgp0.pgp Description: PGP signature
Re: ocaml 3.07beta2 is up at people.debian.org/~luther/ocaml
Quoting Sven Luther ([EMAIL PROTECTED]):
> W: ocaml source: newer-standards-version 3.6.0
lintian needs update. BTW, you can now use 3.6.1 as long as you use
debconf for user input during package installation.
> W: ocaml source: outdated-autotools-helper-file config/gnu/config.guess 2001-06-25
> W: ocaml source: outdated-autotools-helper-file config/gnu/config.sub 2001-06-08
Maybe you can consider using in debian/rules a system for
automagically replace upstream-provided config.{guess|sub} files by
more up-to-date ones which come with autotools-dev.
See /usr/share/doc/autotools-dev README's for examples.Or one of
my packages (lifelines or poedit).
Sorry if you're aware of all this so that I try to learn you something
you better know than me...which is perfectly possible... :-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.07beta2 is up at people.debian.org/~luther/ocaml
Quoting Sven Luther ([EMAIL PROTECTED]):
> > > W: ocaml source: newer-standards-version 3.6.0
> >
> > lintian needs update. BTW, you can now use 3.6.1 as long as you use
> > debconf for user input during package installation.
>
> I don't do any user input thingy anymore, so i guess it is ok, wheter i
> use debconf or not.
It is. The "should" about debconf use for user input is the only non
trivial thing that changed.
>
> > > W: ocaml source: outdated-autotools-helper-file config/gnu/config.guess
> > > 2001-06-25
> > > W: ocaml source: outdated-autotools-helper-file config/gnu/config.sub 2001-06-08
> >
> > Maybe you can consider using in debian/rules a system for
> > automagically replace upstream-provided config.{guess|sub} files by
> > more up-to-date ones which come with autotools-dev.
>
> I don't like this, it messes up the .diff.gz file with lot of useless
> config* stuff. What is the best way to handling this ?
Having upstream update their files more often, maybe .. :-)
As far as I have understood, having up-to-date files is important for
porting issues, mostly on exotic architectures. I learned about this
when I got FTBFS'ed because one of my package did not build anymore on
ARM, IA64 or whatever.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
geneweb and ocaml 3.07 : help.. :-)
Well, as some of you may know, I'm not an ocaml expert...I'm even not a coding expert, by the way. I maintain the geneweb package because it's part of my hobby, mostly. Also because I think I can make good work with it as long as it does not invlove digging in the dirt^W code. So I'm needing some Ocaml competences for helping me. With ocaml 3.07 release, the geneweb package does not compile from sources anymore. This is probably trivial, but I cannot handle this by myself. Here are the symptoms : camlp4r pa_ifdef.cmo -DUNIX -o wserver.ppi wserver.mli ocamlc.opt -warn-error A -I `camlp4 -where` -c -intf wserver.ppi File "wserver.mli", line 24, characters 15-46: The type constructor format expects 3 argument(s), but is here applied to 4 argument(s) make[2]: *** [wserver.cmi] Erreur 2 And the offending code : ifdef OCAML_307 then value wprint : format 'a out_channel unit unit -> 'a else value wprint : format 'a out_channel unit -> 'a; (* To be called to print page contents. *) (you will notice the possible OCAML_307 define) I tried to compile with -DOCAML_307 but the same happens. Probably because the define is implicit when camlp4r is the 3.07 version. The only way to get through this is by commenting stuff : (* ifdef OCAML_307 then value wprint : format 'a out_channel unit unit -> 'a else *) value wprint : format 'a out_channel unit -> 'a; (* To be called to print page contents. *) But this is probably silly.. :-) I could ask Daniel de Rauglaudre, upstream author, but I prefer asking here first as Daniel is currently very busy and I'd prefer trying this as a last option I would probably need an ocaml expert as co-maintainer for geneweb... :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: geneweb and ocaml 3.07 : help.. :-)
Quoting Sven Luther ([EMAIL PROTECTED]): > On Fri, Oct 03, 2003 at 08:00:56PM +0200, Remi Vanicat wrote: > > > I could ask Daniel de Rauglaudre, upstream author, but I prefer asking > > > here first as Daniel is currently very busy and I'd prefer trying this > > > as a last option > > > > you should tell upstream that is code does not compile, it may not be > > aware of it. > > Well, he may not care though, as if i am not wrong, he left the ocaml > team on quite bad terms over calmp4. He certainly cares anyway as geneweb is his baby and related to one of his hobbies Thanks for your advice, I'll try removing the OCAML_307 stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: geneweb and ocaml 3.07 : help.. :-)
> Thanks for your advice, I'll try removing the OCAML_307 stuff. Fine. All compiled well and the new geneweb will be on its way to unstable very soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Latest geneweb package now in testing
Thanks to all the great work of core ocaml package maintainers, the latest (and probably final, except for including new debconf translations in some exotic languages) geneweb package has reached the Grail : it is now in testing... :-) Congrats, folks, you made the transition simple and easy and properly helped me to sort out the minor compilation problems I had with the new 3.07 ocaml. À la vôtre... :-) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: D-I translations: tasksel (Denis Barbier mail to -i18n)
Quoting Jérôme Marant ([EMAIL PROTECTED]): > I think that free programs shall not refer to non-free ones. Thou Shall not refer to non-free programs Thou Shall not promote non-free Non-free is Evil Amen :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: D-I translations: tasksel (Denis Barbier mail to -i18n)
> How funny. Well, I prefer this over saying you that I think your reasoning is a kind of bigotry, because I certainly don't want to be offensive to people I consider great contributors to the free software community. Apologies if I indeed sounded offensive. This was just a way of exrepssing my opinion on this topic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Ocaml gettext library?
The geneweb package currently uses its own system for handling its internal translation. I started thinking about asking Daniel de Rauglaudre for using a standard gettext format for i18n. I guess that some standardized ocaml library exists for this. Am I wrong ? I'm not competent enough for implementing this myself and I'm not sure Daniel would be enthusiast for doing this himself, so any help may be welcome. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ocaml gettext library?
Quoting Remi Vanicat ([EMAIL PROTECTED]): > > I guess that some standardized ocaml library exists for this. Am I > > wrong ? > > I know no standardized ocaml library for this. Hmmm. Interesting project if someone is looking for something to code in ocaml:-) I'm absolutely incompetent for thisso let's wait until someone interested AND competent can start such work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: splitting up the ocaml package: summary
> Humm... the split is fine with me, but i just don't like name : > pkgdepends contents > - > ocaml everythingeverything > ocaml-base ocaml-interpreter > ocaml-interpreter > ocaml-compilers (pseudo package) > ocaml-native-compilers compilers *.opt > ocaml-byte-compilers compilers *.byte > liblabltk-ocaml labltk stublibs > liblabltk-ocaml-dev liblabltk-ocaml labltk header > libbase-extra-ocaml extra stublibs > libbase-extra-ocaml-dev libbase-extra-ocaml extra header > libgraphics-ocamlgraphics stublibs > libgraphics-ocaml-devgraphics header I have had a look to my geneweb package. Currently, its dependencccies are: Build-Depends: .../... ocaml-best-compilers, ocaml (>= 3.04), .../... I'm not sure to remember why both are required, by the wayanyway, this currently works by making it use the native compiler on platforms which have one and the byte compiler otherwise My understanding of the above scheme is that I should now use only "ocaml-compilers" which is a pseudo-package for "native" or "byte" depending oin the platform. Am I right? I suppose of course that I need waiting for these to be uploaded in unstable and built on all arches for uploading a modified geneweb. Maybe waiting for the transition packages to reach testing is even better as I will be sure that geneweb entering testing will not be stucked by some weird thing preventing the ocal packages to enter testing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Transition to ocaml 3.08
Quoting Jérôme Marant ([EMAIL PROTECTED]): > If your packages don't use graphic modules from ocaml, you can consider > depending on ocaml-nox rather than ocaml. So, please have a look to geneweb currently build-depends on ocaml. Is it safe to have it depend on ocaml-nox. If I understand correctly, this should minimize the effort for autobuilders, right ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#264898: geneweb: FTBFS: compile error
tags 264898 help thanks Quoting Roland Stigge ([EMAIL PROTECTED]): > Package: geneweb > Version: 4.09-25 > Severity: serious > > Hi, > > trying to build the package in a clean environment (pbuilder chroot), I got: (geneweb not compiling with Ocaml 3.08. Daniel : FTBFS means that the geneweb Debian package fails to build from sources with current Debian development environment) Unfortunately, I just discovered this RC bug before going away for holidays and couldn't even get time for reporting it myself. I have asked for help about it on the debian-ocaml-maint ML as this is a consequence of the recent switch to Ocaml 3.08. I also may need input from Geneweb upstream author. I still need checking if I got some answers while being away. Thanks for your report. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#264898: geneweb: FTBFS: compile error
> If the problem is not fixed before the 28th of August freeze date at the > latest, i will ask for the removal of geneweb from testing so that the ocaml > 3.08 transition can happen. > > > Unfortunately, I just discovered this RC bug before going away for > > holidays and couldn't even get time for reporting it myself. > > Not cool, when will you be back ? > > > I have asked for help about it on the debian-ocaml-maint ML as this is > > a consequence of the recent switch to Ocaml 3.08. I also may need input > > from Geneweb upstream author. I still need checking if I got some > > answers while being away. > > If all else fail, i can prepare uploads of ocaml-3.07 packages, but i would > much prefer not to have to do this. What are the dependencies and build > dependencies of geneweb ? Geneweb does not depend on any ocaml stuff. It only Build-Depends on it: Build-Depends: debhelper (>= 4.1.16), ocaml-best-compilers, ocaml (>= 3.04), doc-base, dh-buildinfo, iso-codes, po-debconf Currently, I have two solutions left: 1) use a copy of Daniel CVS (he fixed geneweb so that it compiles with 3.07 and 3.08) 2) backport code changes needed for correct build to stable geneweb 4.09 I tested 1) and it works. I have a CVS snapshot from 20040815 which builds properly About 2), this needs help from Daniel and he probably prefers releasing the 4.10 version of Geneweb from his CVS. I still have to read possible answers from Daniel but I think that 1) is the most probable way for solving this. Unless I get clues for backporting compiling fixes in the next couple of days, I will build a package from the CVS snapshot I have. Daniel, do you confirm that it is ready for release? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#264898: geneweb: FTBFS: compile error
> > Currently, I have two solutions left: > > > > 1) use a copy of Daniel CVS (he fixed geneweb so that it compiles with > >3.07 and 3.08) > > Go for it. I just uploaded geneweb_4.09+cvs20040815-1 with priority=high (because of RC bug). This is a CVS snapshot of Daniel's repository made on Aug 15th. It has been built with Ocaml 3.08 without problem. #264898 will then be closed by it, thus the fixed geneweb will be able to enter testing and not interfere with the ocaml transition if it currently does. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coq ne compile plus avec ocaml 3.08.1
> La compilation de coq ne passe plus avec ocaml 3.08.1, sans doute à > cause des modifications de camlp4 (camlp4 parsing of patterns now > conforms to normal parsing (PR#3015) ?). Thankfully, that release was supposed to be a bugfix release. In my mind, this would mean that the new software is supposed to avoid breaking anything. Looks like ocaml developers and I do not share the same views on stable releases Of course, I deeply fear what will happen for the geneweb compilation. I just avoided it to be dropped out from sarge because it didn't compile anymore with 3.08 : I don't want this to happen again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coq ne compile plus avec ocaml 3.08.1
> Thanks. geneweb is already built on most arches, except : arm, m68k, mips and > mipsel. That said, you uploaded with urgency low, which would mean that you > won't make the deadline, you should have done it with urgency=medium, but i As we discussed on IRC, I indeed uploaded with urgency=high, so no problem as vorlon confirmed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Droit de distribuer la doc de coq
Quoting Samuel Mimram ([EMAIL PROTECTED]): > De plus, le package ira dans la section non-free de Debian, sauf si vous > choisissez une licence libre pour cette doc (la licence ci-dessus ne > l'est pas). Maybe explaining to the people you're talking to why this licence is not considered DFSG-compliant would help them. I would maybe help some people here as well..:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335578: ocamlopt.opt segfaults on Alpha
Quoting Falk Hueffner ([EMAIL PROTECTED]): > This breaks building geneweb and probably a whole bunch of other Which could be ween as "breaks unrelated software" by the way. I'm not fond of overflated severities but, well, my pet package (geneweb) is actually blocked by thisso I really hope that someone will be able to take care of this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335578: ocamlopt.opt segfaults on Alpha
(Falk, please tell us if you don't want to be CC'ed to further answers) Quoting Sven Luther ([EMAIL PROTECTED]): > On Tue, Oct 25, 2005 at 08:39:26AM +0200, Christian Perrier wrote: > > Quoting Falk Hueffner ([EMAIL PROTECTED]): > > > > > This breaks building geneweb and probably a whole bunch of other > > > > Which could be ween as "breaks unrelated software" by the way. > > > > I'm not fond of overflated severities but, well, my pet package > > (geneweb) is actually blocked by thisso I really hope that someone > > will be able to take care of this. > > Christian, can you rebuild geneweb using bytecode on alpha, and downgrade this > bug to important ? The bug actually *is* important and I do not really intent to make it "serious". I'm not sure about the right way to recompile geneweb with bytecode on alpha. Actually, this is done in debian/rules with: PACKAGE=geneweb WAY=$(shell if [ -f "/usr/bin/ocamlc.opt" ]; then echo "opt"; \ else echo "out";\ fi) Then $WAY is used to compile one way or another. I guess that adding a specific test for Alpha architecture here would be the Right Hack. Something like: DEB_HOST_ARCH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) ifeq ($(DEB_HOST_ARCH_OS),alpha) WAY=out else WAY=$(shell if [ -f "/usr/bin/ocamlc.opt" ]; then echo "opt"; \ else echo "out";\ fi) endif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335578: ocamlopt.opt segfaults on Alpha
> > > Christian, can you rebuild geneweb using bytecode on alpha, and downgrade > > > this > > > bug to important ? > > > > > > The bug actually *is* important and I do not really intent to make it > > "serious". > > Ah, ok. Still, you need to be able to build on alpha :) Done. I uploaded a new version which should build using bytecode on alpha if my debian/rules changes aren't wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.09.0 and word from the RMs ...
> 2) other uploads, like ocurl, and maybe approx, cduce, or geneweb, which > happened recently and are not yet in testing. These we have the choice to > wait or have them go in with the ocaml 3.09.0 stuff. Speaking for geneweb, no problem for me if my last upload doesn't go to testing and if I have to rebuild the package once more. The version currently in testing is rock solid and the changes were minimal (a few LSB init scripts things). Well, I'll be happy if it goes be fore ocaml 3.09 enters unstable, but I won't be angry otherwise Actually, my main concern is whether the alpha crash is solved or not with ocaml 3.09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted ocaml 3.09.0-0.experimental.1 (source all powerpc)
> ocaml (3.09.0-0.experimental.1) experimental; urgency=low Hmmm, any chance that one can check about ocamlopt.opt no more crashing on alphas? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#335578: ocamlopt.opt segfaults on Alpha
> As said on irc, the likely solution here would be to disable the alpha native > compilers until the solution is found. Done in geneweb, which allowed it to enter testing. I'm currently rebuilding geneweb with 3.09, btw. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.09.0: alpha and m68k:tk8.4 problems seem solved ...
Quoting Sven Luther ([EMAIL PROTECTED]): > Once that is done, we can proceed with the other uploads. And in particular > Christian can revert his alpha patch. Sure. If I can manage to compile geneweb with ocaml 3.09..:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.09.0: alpha and m68k:tk8.4 problems seem solved ...
Quoting Sven Luther ([EMAIL PROTECTED]): > On Tue, Nov 08, 2005 at 10:23:39PM +0100, Christian Perrier wrote: > > Quoting Sven Luther ([EMAIL PROTECTED]): > > > > > Once that is done, we can proceed with the other uploads. And in > > > particular > > > Christian can revert his alpha patch. > > > > > > Sure. If I can manage to compile geneweb with ocaml 3.09..:-) > > What's the problem ? camlp4r pa_extend.cmo q_MLast.cmo pa_ifdef.cmo -DUNIX -o pa_html.ppo pa_html.ml Warning: pa_ifdef is deprecated since OCaml 3.07. Use pa_macro instead. ocamlc.opt -I ../wserver -I ../dag2html -I `camlp4 -where` -c -impl pa_html.ppo File "pa_html.ml", line 30, characters 0-1: Unbound value _loc make[2]: *** [pa_html.cmo] Erreur 2 I notified Daniel about this.waiting for the answer (which I will probably get) I CC'ed this very list to my request but I unfortunately messed up in the list address, thinking it is an Alioth list, which it isn't...:-| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.09.0: alpha and m68k:tk8.4 problems seem solved ...
> Ah, this is the camlp4 loc -> _loc change, see at how we fixed ledit for
> example (a simple 2 line fix in a 30 line file, so easy to look at).
>
> > I notified Daniel about this.waiting for the answer (which I will
> > probably get)
>
> Yeah, but given the politics surrounding camlp4 and that Daniel left angry and
> may not approve those camlp4 changes, you may well be prepared to fix this
> yourself. I may be wrong though.
Well, he gave me a correct fix ("CAMLP4F=-DUNIX -loc loc" in
tools/Makefile.inc.o*)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ocaml 3.09.0: alpha and m68k:tk8.4 problems seem solved ...
> Yeah, it reverts the loc thingy to the old behavior. That is the easy fix, the > other is doing a sed -i -e 's%loc%_loc%g' on all your source files. I'll leave this to Daniel in upstream sources...:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please don't upload yet, until we have a working alpha ocaml test suite.
> All packages which where uploaded and built before the binNMU alpha was > installed will need to be binNMUed, thanks for having a look at the ones you > uploaded. /me turns self in wait mode..:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transition status
Quoting Julien Cristau ([EMAIL PROTECTED]): > Hi, > > here is the status for the 3.09.1 transition: I haven't asked you folks, as I think I know the answer, but let's get a confirmation. Do I need to do a new build of geneweb? I assumed I don't but better be sure..:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377574: mldonkey: [INTL:fr] French debconf templates translation
Package: mldonkey Version: N/A Severity: wishlist Tags: patch l10n Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. If you do not already use it, please remember about the "podebconf-report-po" utility, which helps warning translators about changes when you modify some debconf templates in your packages. See its man page for details. The usual policy when using it is sending a warning to translators when you plan to upload a version of your package with debconf templates changes (EVEN TYPO CORRECTIONS). Then leave about one week for them to update their files (several translation teams have a QA process which requires time). podebconf-report-po will take care of sending the translators the needed material as well as getting the translators adresses from the PO files. All you have to do is just using the utility..:-) If you apply this policy, please forget about these remarks, of courseThis message is generic..:-) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) # translation of fr.po to French # Translators, if you are not familiar with the PO format, gettext # documentation is worth reading, especially sections dedicated to # this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # Some information specific to po-debconf are available at # /usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # Developers do not need to manually edit POT or PO files. # # <>, 2003. # Christian Perrier <[EMAIL PROTECTED]>, 2006. msgid "" msgstr "" "Project-Id-Version: fr\n" "Report-Msgid-Bugs-To: [EMAIL PROTECTED]" "POT-Creation-Date: 2006-06-23 09:41+\n" "PO-Revision-Date: 2006-06-24 19:12+0200\n" "Last-Translator: Christian Perrier <[EMAIL PROTECTED]>\n" "Language-Team: French \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=ISO-8859-1\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: KBabel 1.11.2\n" #. Type: note #. Description #: ../mldonkey-server.templates:3 msgid "Bug #200500" msgstr "Bogue numéro 200500" #. Type: note #. Description #: ../mldonkey-server.templates:3 msgid "" "Previous versions of mldonkey-server suffer from a serious DFSG policy " "violation." msgstr "" "Les versions précédentes de mldonkey-server comportaient un sérieux problème " "de violation de la définition des logiciels libres selon Debian (« Debian " "Free Software Guidelines »)." #. Type: note #. Description #: ../mldonkey-server.templates:3 msgid "" "The plugin for the fasttrack protocol (e.g. used by kazaa) of mldonkey-" "server was made with illegal coding practice. This version fixes the problem " "by removing this plugin from the MLDonkey package. Any fasttrack sources " "will be filtered out of your files.ini." msgstr "" "Le greffon fasttrack (utilisé par exemple pour kazaa) de mldonkey-server " "relevait de pratiques illégales de programmation. Cette version corrige ce " "problème. Toutes les références à fasttrack seront supprimées de votre " "fichier files.ini." #. Type: note #. Description #: ../mldonkey-server.templates:3 msgid "" "Your entire fasttrack upload will disappear with the next restart of the " "mldonkey server." msgstr "" "Tous vos téléchargements fasttrack disparaîtront au prochain redémarrage de " "mldonkey." #. Type: note #. Description #: ../mldonkey-server.templates:3 msgid "See /usr/share/doc/mldonkey-server/README.Debian for more information." msgstr "" "Veuillez consulter le fichier /usr/share/doc/mldonkey-server/README.Debian " "pour plus d'informations." #. Type: boolean #. Description #: ../mldonkey-server.templates:20 msgid "Launch MLDonkey at startup?" msgstr "Faut-il lancer MLDonkey au démarrage du système ?" #. Type: boolean #. Description #: ../mldonkey-server.templates:20 msgid "" "If enabled, each time your machine starts, the MLDonkey server will be " "started." msgstr "" "Si vous choisissez cette option, un serveur MLDonkey sera lancé à chaque démarrage de " "votre machine." #. Type: boolean #. Description #: ../mldonkey-server.templates:20 msgid "" "Otherwise, you
Re: svn commit notifications sent to this list
> So, here comes the poll: does subscribing this list to the -commit list > of the pkg-ocaml-maint alioth project bother any of you, guys? Well, I would say that I'm not fond of it. I'm actually subscribed to -maint mostly because I maintain one Ocaml-related package and want to hear about possible transition/problems with Ocaml stuff. Getting commit messages would be extra useless stuff for me and I'd vote for keeping the lists separated. However, I'm not an active member in the community here so don't consider my advice with too much value. If changing things is suitable and valuable for you guys, then I'm OK with that and I'll live with that. signature.asc Description: Digital signature
Bug#418980: ocaml-tools: Invalid german translation file for debconf templates
Package: ocaml-tools Severity: normal Tags: patch l10n The german translation of ocaml-tools debconf templates is invalid because of extra "msgstr". I recommend checking PO files before sending them: msgfmt -o /dev/null --statistics file.po Please use the attached patch on the debian/po/de.po file. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-486 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- de.po 2007-04-13 07:35:31.0 +0200 +++ de2.po 2007-04-13 07:40:13.329185616 +0200 @@ -27,7 +27,7 @@ "Omlet is an enhanced vim mode for OCaml which has better indentation than " "the official vim mode for OCaml. You don't need this if you don't use vim." msgstr "" -msgstr "Omlet ist ein erweiterter vim-Modus für OCaml, welcher über eine " +"Omlet ist ein erweiterter vim-Modus für OCaml, welcher über eine " "verbesserte Markierung als der offizielle vim-Modus für OCaml verfügt. Sie " "benötigen dies nicht, falls Sie keinen vim benutzen." @@ -36,5 +36,5 @@ #: ../ocaml-tools.templates:1001 msgid "Do you want to use it as the default mode for editing ml files?" msgstr "" -msgstr "Wollen Sie diesen Modus standardmäßig zum Bearbeiten von ml-Dateien " +"Wollen Sie diesen Modus standardmäßig zum Bearbeiten von ml-Dateien " "verwenden?"
Bug#418980: ocaml-tools: Invalid german translation file for debconf templates
> > Please use the attached patch on the debian/po/de.po file. > > Will you take care, i.e. apply the patch, or is a new file from the > translator / the German team required? Care should be taken by the package maintainer (which I am not...I noticed the error while checking the logs from the -still experimental- i18n server). I think that the patch I provided should be enough for the maintainer to use...but a new de.po file will not hurt anyway..:) signature.asc Description: Digital signature
Re: Bug#441508: geneweb - FTBFS: ./tools/camlp4_comm.sh: line 27: camlp4r: command not found
Quoting Michael Ablassmeier ([EMAIL PROTECTED]): > Package: geneweb > Version: 5.00-5 > Severity: serious > User: [EMAIL PROTECTED] > Usertags: qa-ftbfs-20070905 > > hi, > > while doing an archive wide package rebuild your package failed to build from > source for the following reason: > > camlp4r pa_macro.cmo -loc loc -o ppdef.ppo ppdef.ml > > ../tools/camlp4_comm.sh: line 27: camlp4r: command not found This is apparently triggerred by the changes in the ocaml package with camlp4 becoming a separate package. I probably should have noticed thatif only I read the debian-ocaml-maint ML..:-) The patch is then obvious here: build-depend on camlp4 signature.asc Description: Digital signature
Re: dag2html: a package in need of some love
Quoting James Westby ([EMAIL PROTECTED]): > For the geneweb part I am Ccing Christian. Christian, do you know of > anybody that would be interested in the dag2html package? Would it > be worth contacting your upstream? I don't have any real idea of who could be interested in it. However, on should note that dag2html is currently distributed along with Geneweb sources. So, geneweb could indeed provide a dag2html package itself as it seems. signature.asc Description: Digital signature
Re: dag2html: a package in need of some love
Quoting James Westby ([EMAIL PROTECTED]): > Is it an updated version, or still the same code do you know? [EMAIL PROTECTED]:~/src/debian/geneweb/geneweb-5.01/dag2html> ls -l total 88 -rw--- 1 bubulle bubulle 1936 jan 1 2006 dag2html.1 -rw--- 1 bubulle bubulle 42802 déc 13 2005 dag2html.ml -rw--- 1 bubulle bubulle 1074 déc 13 2005 dag2html.mli drwx-- 2 bubulle bubulle46 sep 12 2007 ex -rw--- 1 bubulle bubulle 18007 déc 13 2005 LICENSE -rw--- 1 bubulle bubulle 7307 oct 15 2006 main.ml -rw--- 1 bubulle bubulle 743 jui 11 2007 Makefile -rw--- 1 bubulle bubulle 1368 jui 11 2007 README [EMAIL PROTECTED]:~/src/debian/geneweb/geneweb-5.01/dag2html> grep Id * dag2html.ml:(* $Id: dag2html.ml,v 5.0 2005/12/13 11:51:26 ddr Exp $ *) dag2html.mli:(* $Id: dag2html.mli,v 5.0 2005/12/13 11:51:26 ddr Exp $ *) main.ml:(* $Id: main.ml,v 5.1 2006/10/15 15:39:38 ddr Exp $ *) Makefile:# $Id: Makefile,v 5.1 2007/07/11 16:15:21 ddr Exp $ signature.asc Description: Digital signature
Re: dag2html: a package in need of some love
Quoting Barry deFreese ([EMAIL PROTECTED]): > Christian Perrier wrote: >> Quoting James Westby ([EMAIL PROTECTED]): >> >> >>> Is it an updated version, or still the same code do you know? >>> >> >> >> >> >> > I've file a preliminary proposed removal for dag2html. I then suggest that, as soon as it's been removed from unstable, you file a wishlist BR against geneweb for it to provide a binary package for dag2html. signature.asc Description: Digital signature
Intent to NMU or help for an l10n upload of mldonkey to fix pending po-debconf l10n bugs
Dear Debian maintainer, The mldonkey Debian package, which you are the maintainer of, has pending bug report(s) which include translation updates or fixes for po-debconf, namely bug number 480751 (and maybe other similar bugs). Even though this bug is quite recent, the release of Debian is not that far and an opportunity should be taken to not only fix that l10n bug, but also get more translations for your package. I have the intention, as part of a more general action of the Debian i18n Task Force to build and possibly upload a non-maintainer upload for mldonkey in order to fix this as well as all pending translations for the debconf templates. Of course, as you seem pretty active on that package, an upload by you would also be OK...as long as it allows a round of translation updates. Such changes are always harmless, which explains why I safely consider building NMU's for such issues even though they're obviously non critical. The schedule for the NMU (in case it happens, that is if you agree with it or if I don't receive any answer in 14 days) is roughly the following: Thursday, July 24, 2008 : send this notice Thursday, August 07, 2008 : post a NMU announcement to debian-i18n with you (maintainer) CC'ed Sunday, August 17, 2008 : deadline for receiving translation updates Monday, August 18, 2008 : build the package and upload it to DELAYED/2-day send the NMU patch to the BTS Wednesday, August 20, 2008 : NMU reaches incoming If you intent to upload yourself, please discuss with me. I propose handling a translation update round and I can handle it myself for you. That will just require a few days. In case I upload an NMU, I will subscribe to the Package Tracking System for mldonkey and follow its life for 60 days after my NMU in order to fix any issue potentially introduced by my upload. Let me know, as soon as possible, if you have any kind of objection to this process. If you'd rather do the fix yourself, I will of course leave the package alone. Same if you have reasons not to do the update now. -- signature.asc Description: Digital signature
Bug#480751: Announce of the upcoming NMU for the mldonkey package
Dear maintainer of mldonkey and Debian translators, Some days ago, I sent a notice to the maintainer of the mldonkey Debian package, mentioning the status of at least one old po-debconf translation update in the BTS. I announced the intent to build and possibly upload a non-maintainer upload for this package in order to fix this long-time pending localization bug as well as all other pending translations. The package maintainer agreed for the NMU or did not respond in two weeks, so I will proceed with the NMU. The full planned schedule is available at the end of this mail. The package is currently translated to: ca cs de es eu fi fr gl it nl pt sv vi Among these, the following translations are incomplete: es vi If you did any of the, currently incomplete, translations you will get ANOTHER mail with the translation to update. Other translators also have the opportunity to create new translations for this package. Once completed, please send them as a bug report against the mldonkey package so I can incorporate them in the build. The deadline for receiving updates and new translations is Monday, August 11, 2008. If you are not in time you can always send your translation to the BTS. The POT file is attached to this mail. If the maintainer objects to this process I will immediately abort my NMU and send him/her all updates I receive. Otherwise the following will happen (or already has): Thursday, July 24, 2008 : send the first intent to NMU notice to the package maintainer. Monday, August 04, 2008 : send this notice Monday, August 11, 2008 : (midnight) deadline for receiving translation updates Tuesday, August 12, 2008 : build the package and upload it to DELAYED/2-day send the NMU patch to the BTS Thursday, August 14, 2008 : NMU uploaded to incoming Thanks for your efforts and time. -- -- # SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR <[EMAIL PROTECTED]>, YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: [EMAIL PROTECTED]" "POT-Creation-Date: 2008-05-05 22:32+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <[EMAIL PROTECTED]>\n" "Language-Team: LANGUAGE <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=CHARSET\n" "Content-Transfer-Encoding: 8bit\n" #. Type: note #. Description #: ../mldonkey-server.templates:1001 msgid "Bug #200500" msgstr "" #. Type: note #. Description #: ../mldonkey-server.templates:1001 msgid "" "Previous versions of mldonkey-server suffer from a serious DFSG policy " "violation." msgstr "" #. Type: note #. Description #: ../mldonkey-server.templates:1001 msgid "" "The plugin for the fasttrack protocol (e.g. used by kazaa) of mldonkey-" "server was made with illegal coding practice. This version fixes the problem " "by removing this plugin from the MLDonkey package. Any fasttrack sources " "will be filtered out of your files.ini." msgstr "" #. Type: note #. Description #: ../mldonkey-server.templates:1001 msgid "" "Your entire fasttrack upload will disappear with the next restart of the " "mldonkey server." msgstr "" #. Type: note #. Description #: ../mldonkey-server.templates:1001 msgid "See /usr/share/doc/mldonkey-server/README.Debian for more information." msgstr "" #. Type: boolean #. Description #: ../mldonkey-server.templates:2001 msgid "Launch MLDonkey at startup?" msgstr "" #. Type: boolean #. Description #: ../mldonkey-server.templates:2001 msgid "" "If enabled, each time your machine starts, the MLDonkey server will be " "started." msgstr "" #. Type: boolean #. Description #: ../mldonkey-server.templates:2001 msgid "" "Otherwise, you will need to launch MLDonkey yourself each time you want to " "use it." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:3001 msgid "MLDonkey user:" msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:3001 msgid "Define the user who will run the MLDonkey server process." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:3001 msgid "" "Please do not choose a real user. For security reasons it is better if this " "user does not own any other data than the MLDonkey share." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:3001 msgid "" "You will use this user account to share and get data from the peer-to-peer " "networks." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:3001 msgid "" "This user will be a system user (if created). You won't be able to login " "into your system with this user name." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:4001 msgid "MLDonkey group:" msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:4001 msgid "Define the group which wi
Accepted mldonkey 2.9.5-1.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 24 Jul 2008 08:44:48 +0200 Source: mldonkey Binary: mldonkey-server mldonkey-gui Architecture: source i386 Version: 2.9.5-1.1 Distribution: unstable Urgency: low Maintainer: Debian OCaml Maintainers Changed-By: Christian Perrier <[EMAIL PROTECTED]> Description: mldonkey-gui - Graphical frontend for mldonkey based on GTK+ mldonkey-server - Door to the 'donkey' network Closes: 480751 492549 493175 493754 494399 Changes: mldonkey (2.9.5-1.1) unstable; urgency=low . * Non-maintainer upload to fix pending l10n issues. * Debconf translations: - Italian. Closes: #480751 - Finnish. Closes: #492549 - Swedish. Closes: #493175 - Russian. Closes: #493754 - Japanese. Closes: #494399 Checksums-Sha1: 763695c4a6f50f67aff6f6564adbc1cb4944623a 1582 mldonkey_2.9.5-1.1.dsc 66367e78eb07df93ada767d8e50e5081cc7749f6 136684 mldonkey_2.9.5-1.1.diff.gz 9f156bcc3e8acf410bb32d68d66228de98e5a1d5 2499208 mldonkey-server_2.9.5-1.1_i386.deb 867944f5e20e3ef7e05cd006b5740a15f78083e2 3684108 mldonkey-gui_2.9.5-1.1_i386.deb Checksums-Sha256: 6af8de9e43dba91379f0c81c7631f1614e8bc9cb698c5b4363ac558e7b6387c4 1582 mldonkey_2.9.5-1.1.dsc 4541fee4e32b18349f64d2b5e3bd510e43ec938f6ce56a58111dd24509600eee 136684 mldonkey_2.9.5-1.1.diff.gz 56f92a0744d4cfa09db62aa89abf3f8e030f05177f649fd2c21db8715f16f8da 2499208 mldonkey-server_2.9.5-1.1_i386.deb 49ba91e76d4c18092b22124821e9bb4cad9859c6912d09473eaa1360a2a0ee05 3684108 mldonkey-gui_2.9.5-1.1_i386.deb Files: 4bab1df58a51d5f158d0630f0334bff3 1582 net optional mldonkey_2.9.5-1.1.dsc dc6dd0568a1bc0a374afa4c673580da7 136684 net optional mldonkey_2.9.5-1.1.diff.gz b4dc92cf8fd424e4c519afa58f9f39e5 2499208 net optional mldonkey-server_2.9.5-1.1_i386.deb 47053e3198e7d3a97418a7792b462e08 3684108 net optional mldonkey-gui_2.9.5-1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkih3vIACgkQ1OXtrMAUPS30mQCfZs5qxVXxoIF1meCM7ok2s5Wk HXYAoKqkadLzwSPX8sBjufjv8N1hxE6c =w/UE -END PGP SIGNATURE- Accepted: mldonkey-gui_2.9.5-1.1_i386.deb to pool/main/m/mldonkey/mldonkey-gui_2.9.5-1.1_i386.deb mldonkey-server_2.9.5-1.1_i386.deb to pool/main/m/mldonkey/mldonkey-server_2.9.5-1.1_i386.deb mldonkey_2.9.5-1.1.diff.gz to pool/main/m/mldonkey/mldonkey_2.9.5-1.1.diff.gz mldonkey_2.9.5-1.1.dsc to pool/main/m/mldonkey/mldonkey_2.9.5-1.1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to NMU mldonkey to fix pending po-debconf l10n bugs
Dear Debian maintainer, The mldonkey Debian package, which you are the maintainer of, has pending bug report(s) which include translation updates or fixes for po-debconf, namely bug number 498567 (and maybe other similar bugs). We're now getting very close to the release and fixing l10n bugs should be done now. Letting such bugs sleep in the BTS is simply lowering the chances that your package interaction with its users may be done in something else than the English language. It is also not encouraging for translators. I have the intention, as part of a more general action of the Debian i18n Task Force to build and possibly upload a non-maintainer upload for mldonkey in order to fix this as well as all pending translations for the debconf templates. Of course, an upload made by you would even be better...:-) Such changes are always harmless, which explains why I safely consider building NMU's for such issues even though they're obviously non critical. The schedule for the NMU (in case it happens, that is if you agree with it or if I don't receive any answer in 10 days) is roughly the following: Sunday, October 19, 2008 : send this notice Thursday, October 23, 2008 : post a NMU announcement to debian-i18n with you (maintainer) CC'ed this can happen earlier if the maintainer agrees In such case, the deadlines below will also happen earlier Wednesday, October 29, 2008 : (midnight) deadline for receiving translation updates Thursday, October 30, 2008 : build the package and upload it to DELAYED/2-day send the NMU patch to the BTS Saturday, November 01, 2008 : NMU reaches incoming If you intent to upload yourself, please notify me so that I interrupt the process on my side. Please also don't upload without a discussion with me. Some translators might send a few new translations and I can handle a round of translation updates for you. Really, don't upload silently...:-) In case I upload an NMU, I will subscribe to the Package Tracking System for mldonkey and follow its life for 60 days after my NMU in order to fix any issue potentially introduced by my upload. Let me know, as soon as possible, if you have any kind of objection to this process. If you'd rather do the fix yourself, I will of course leave the package alone. Same if you have reasons not to do the update now. -- signature.asc Description: Digital signature
Bug#498567: Announce of an upcoming upload for the mldonkey package
Dear maintainer of mldonkey and Debian translators, Some days ago, I sent a notice to the maintainer of the mldonkey Debian package, mentioning the status of at least one old po-debconf translation update in the BTS. The package maintainer and I agreed for a translation update round. At the end of this period, I will send him|her a full patch so that an l10n upload can happen. The full planned schedule is available at the end of this mail. The package is currently translated to: ca cs de es eu fi fr gl it ja nl pt ru sv vi Among these, the following translations are incomplete: es vi If you did any of the, currently incomplete, translations you will get ANOTHER mail with the translation to update. Other translators also have the opportunity to create new translations for this package. Once completed, please send them as a bug report against the mldonkey package so I can incorporate them in the build. The deadline for receiving updates and new translations is Sunday, October 26, 2008. If you are not in time you can always send your translation to the BTS. The POT file is attached to this mail. Schedule: Sunday, October 19, 2008 : send the first intent to NMU notice to the package maintainer. Monday, October 20, 2008 : send this notice Sunday, October 26, 2008 : (midnight) deadline for receiving translation updates Monday, October 27, 2008 : Send a summary to the maintainer. Maintainer uploads when possible. Thanks for your efforts and time. -- -- # SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR <[EMAIL PROTECTED]>, YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: [EMAIL PROTECTED]" "POT-Creation-Date: 2008-05-05 22:32+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <[EMAIL PROTECTED]>\n" "Language-Team: LANGUAGE <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=CHARSET\n" "Content-Transfer-Encoding: 8bit\n" #. Type: note #. Description #: ../mldonkey-server.templates:1001 msgid "Bug #200500" msgstr "" #. Type: note #. Description #: ../mldonkey-server.templates:1001 msgid "" "Previous versions of mldonkey-server suffer from a serious DFSG policy " "violation." msgstr "" #. Type: note #. Description #: ../mldonkey-server.templates:1001 msgid "" "The plugin for the fasttrack protocol (e.g. used by kazaa) of mldonkey-" "server was made with illegal coding practice. This version fixes the problem " "by removing this plugin from the MLDonkey package. Any fasttrack sources " "will be filtered out of your files.ini." msgstr "" #. Type: note #. Description #: ../mldonkey-server.templates:1001 msgid "" "Your entire fasttrack upload will disappear with the next restart of the " "mldonkey server." msgstr "" #. Type: note #. Description #: ../mldonkey-server.templates:1001 msgid "See /usr/share/doc/mldonkey-server/README.Debian for more information." msgstr "" #. Type: boolean #. Description #: ../mldonkey-server.templates:2001 msgid "Launch MLDonkey at startup?" msgstr "" #. Type: boolean #. Description #: ../mldonkey-server.templates:2001 msgid "" "If enabled, each time your machine starts, the MLDonkey server will be " "started." msgstr "" #. Type: boolean #. Description #: ../mldonkey-server.templates:2001 msgid "" "Otherwise, you will need to launch MLDonkey yourself each time you want to " "use it." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:3001 msgid "MLDonkey user:" msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:3001 msgid "Define the user who will run the MLDonkey server process." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:3001 msgid "" "Please do not choose a real user. For security reasons it is better if this " "user does not own any other data than the MLDonkey share." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:3001 msgid "" "You will use this user account to share and get data from the peer-to-peer " "networks." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:3001 msgid "" "This user will be a system user (if created). You won't be able to login " "into your system with this user name." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:4001 msgid "MLDonkey group:" msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:4001 msgid "Define the group which will run the MLDonkey server process." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:4001 msgid "" "Please do not choose a real group. For security reasons it is better if this " "group does not own any other data than the MLDonkey share." msgstr "" #. Type: string #. Description #: ../mldonkey-server.templates:4001 msgid "" "Us
Bug#498567: Patch for the l10n upload of mldonkey
Dear maintainer of mldonkey, On Monday, October 20, 2008 I sent you a notice announcing my intent to upload a NMU of your package to fix its pending l10n issues, after an initial notice sent on Sunday, October 19, 2008. We finally agreed that you would do the update yourself at the end of the l10n update round. That time has come. To help you out, here's the patch which I would have used for an NMU. Please feel free to use all of it...or only the l10n part of it. The corresponding changelog is: Source: mldonkey Version: 2.9.5-1.2 Distribution: unstable Urgency: low Maintainer: Christian Perrier <[EMAIL PROTECTED]> Date: Mon, 27 Oct 2008 08:09:45 +0100 Closes: 498567 Changes: mldonkey (2.9.5-1.2) unstable; urgency=low . * Non-maintainer upload. * Fix pending l10n issues. Debconf translations: - Japanese. Closes: #498567 -- diff -Nru mldonkey-2.9.5.old/debian/changelog mldonkey-2.9.5/debian/changelog --- mldonkey-2.9.5.old/debian/changelog 2008-10-18 22:32:59.812403448 +0200 +++ mldonkey-2.9.5/debian/changelog 2008-10-27 08:09:50.946730629 +0100 @@ -1,3 +1,11 @@ +mldonkey (2.9.5-1.2) unstable; urgency=low + + * Non-maintainer upload. + * Fix pending l10n issues. Debconf translations: +- Japanese. Closes: #498567 + + -- Christian Perrier <[EMAIL PROTECTED]> Mon, 27 Oct 2008 08:09:45 +0100 + mldonkey (2.9.5-1.1) unstable; urgency=low * Non-maintainer upload to fix pending l10n issues. diff -Nru mldonkey-2.9.5.old/debian/po/ja.po mldonkey-2.9.5/debian/po/ja.po --- mldonkey-2.9.5.old/debian/po/ja.po 2008-10-18 22:32:59.584403244 +0200 +++ mldonkey-2.9.5/debian/po/ja.po 2008-10-19 10:07:17.556403000 +0200 @@ -8,7 +8,7 @@ "Project-Id-Version: mldonkey 2.9.5-1\n" "Report-Msgid-Bugs-To: [EMAIL PROTECTED]" "POT-Creation-Date: 2008-05-05 22:32+0200\n" -"PO-Revision-Date: 2008-07-31 11:21+0200\n" +"PO-Revision-Date: 2008-09-11 16:11+0200\n" "Last-Translator: Hideki Yamane (Debian-JP) <[EMAIL PROTECTED]>\n" "Language-Team: Japanese <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" @@ -52,8 +52,8 @@ "Your entire fasttrack upload will disappear with the next restart of the " "mldonkey server." msgstr "" -"次回に mldonkey サーバをした時から fasttrack を使ったアップロードは完全にでき" -"なくなります。" +"次回に mldonkey サーバを起動し直した時から fasttrack を使ったアップロードは完" +"全にできなくなります。" #. Type: note #. Description @@ -156,8 +156,8 @@ "Users of this group can start and stop the MLDonkey server and can also " "access the files fetched from the peer-to-peer networks." msgstr "" -"このグループに属するユーザは MLDonkey サーバを開始／停止することや P2P ネッ" -"トワークでデータをやりとりしたファイルへのアクセスが可能です。" +"このグループに属するユーザは MLDonkey サーバを開始／停止することや P2P ネット" +"ワークでデータをやりとりしたファイルへのアクセスが可能です。" #. Type: boolean #. Description @@ -183,7 +183,7 @@ "it yourself later (e.g. with deluser(8)), or you keep it along with the old " "configuration." msgstr "" -"PS: 以前のユーザは /etc/passwd から削除されません、後ほど自分で作業する必要が" +"PS: 以前のユーザは /etc/passwd から削除されません。後ほど自分で削除する必要が" "あります (例えば deluser(8) などを使う)。あるいは古い設定のままにしておくか、" "です。" @@ -244,8 +244,8 @@ "If you choose no, the old directory won't be deleted. You will have to do it " "yourself." msgstr "" -"「いいえ」を選んでも、以前のディレクトリは削除されません。自分で行う必要があ" -"るだけです。" +"「いいえ」を選んでも、以前のディレクトリは削除されません。自分で削除をする必" +"要があります。" #. Type: string #. Description signature.asc Description: Digital signature
Bug#521674: FTBFS: "Def.syn" is not a valid module name.
Package: geneweb Version: 5.01-8 Severity: serious Justification: Fails to build from source Trying to recompile the geneweb package in sid gives: camlp5r pa_extend.cmo q_MLast.cmo pa_macro.cmo -DUNIX -o def.syn.ppo def.syn.ml ocamlc.opt -warn-error A -I ../wserver -I ../dag2html -I +camlp5 -c -impl def.syn.ppo File "def.syn.ppo", line 1, characters 0-1: Warning X: bad source file name: "Def.syn" is not a valid module name. File "def.syn.ml", line 1, characters 0-1: Error: Error-enabled warnings (1 occurrences) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages geneweb depends on: ii adduser 3.110 add and remove users and groups ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii iso-codes 3.7-1 ISO language, territory, currency, ii libc6 2.9-6 GNU C Library: Shared libraries ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip ii perl-base [perl5-base]5.10.0-19 minimal Perl system geneweb recommends no packages. Versions of packages geneweb suggests: ii gwsetup5.01-8utilities to configure and manipul ii gwtp 5.01-8web interface interacting with Gen ii iceweasel [www-browser 3.0.7-1 lightweight web browser based on M ii konqueror [www-browser 4:3.5.10.dfsg.1-2 KDE's advanced file manager, web b ii lynx 2.8.7pre1-1 Text-mode WWW Browser (transitiona ii lynx-cur [www-browser] 2.8.7pre1-1 Text-mode WWW Browser with NLS sup ii menu 2.1.41generates programs menu for all me ii w3m [www-browser] 0.5.2-2+b1WWW browsable pager with excellent ii xemacs21-mule [www-bro 21.4.22-1 highly customizable text editor -- ii xemacs21-nomule [www-b 21.4.22-1 highly customizable text editor -- -- debconf information excluded -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#521674: FTBFS: "Def.syn" is not a valid module name.
Quoting Stéphane Glondu (st...@glondu.net): > tags 521674 + upstream patch > thanks Thanks for the patch. > > Stéphane Glondu a écrit : > > You can workaround this failure by adding "-w x" to the failing command > > line. It will disable the warning (which is an error because of > > -warn-error). You can also remove -warn-error (your call). > > I can see in the changelog entry of 4.10-15 that "-warn-error A" has > already been removed in the past for the same reason. I suggest to do > the same this time. > > > The proper solution would be to ask upstream to rename the file into a > > proper module name. > > This still applies. I notified Daniel this morning when I discovered this bug. I'll see what is his reaction. I would very much prefer seeing this fixed upstream and only have to use the workaround if Daniel doesn't want to fix the issue upstream. signature.asc Description: Digital signature
About #335578
(please CC me to replies) Hello Ocamlers, Is #335578 fixed? In geneweb's debian/rules, I still have an old workaround for that bug so that geneweb is builts using bytecode on alpha, until that bug is fixed. Given the timeframe, I wonder if I really should keep this. -- signature.asc Description: Digital signature
Re: Bug#557553: geneweb: Search and navigaition fails
tags 557553 help thanks Quoting Pär-Ola Nilsson (p...@home.se): > >Hmm, I just did the exact same sequence after adding your test > >database to my local tree and.got no error. > > > >Could you send the output of "ls -lR /var/lib/geneweb"? > > > >Are you using unstable or testing? > > > > > It's a mishmash but mostly unstable, some testing and some select > experimental. > > Tried the same thing on a i386 box mostly testing with some unstable > and that works. > Tried the same on another amd64 box mostly unstable and some testing, failes > Another i386 box at work mostly unstable and some testing, works > > Seems its amd64 boxes that fail. Oh, nice catch. So, we apparently have something that fails on amd64 but not i386. I might need some help by the Ocaml team to track this down. It is more and more likely that this goes far beyond my own skills. Ocaml folks, would you mind looking at this bug report that apparently shows up only on amd64, for geneweb? signature.asc Description: Digital signature
Re: Bug#557553: geneweb: Search and navigaition fails
Quoting Wolfgang Rohdewald (wolfg...@rohdewald.de): > I now have the same bug after migrating from ubuntu 9.10 32bit > to ubuntu 10.4 64bit. > > Did anybody already find a solution for this? As of now, no. As already mentioned in the bug history, I need help from Ocaml gurus for this. signature.asc Description: Digital signature
Re: Bug#557553: geneweb: Search and navigaition fails
Quoting Stéphane Glondu (glo...@debian.org):
> Stéphane Glondu a écrit :
> > I was able to reproduce the bug on an amd64 box. Here is a backtrace:
> >
> > Wserver: uncaught exception: End_of_file
> > Raised by primitive operation at file "", line 0, characters 0-0
> > Called from file "some.ml", line 664, characters 14-44
> > Called from file "some.ml", line 688, characters 7-46
> > Called from file "request.ml", line 734, characters 17-35
> > Called from file "request.ml", line 754, characters 12-39
> > Re-raised at file "request.ml", line 755, characters 38-41
> > Called from file "gwd.ml", line 1467, characters 23-116
> > Called from file "gwd.ml", line 1635, characters 12-95
> > Called from file "wserver.ml", line 338, characters 6-51
>
> More precisely, in database.ml, around line 441:
>
> if Sys.file_exists fname_inx_acc then
> let ic_inx_acc = Secure.open_in_bin fname_inx_acc in
> do {
> seek_in ic_inx_acc (Iovalue.sizeof_long * (table_size + i));
> let pos = input_binary_int ic_inx_acc in
> close_in ic_inx_acc;
> seek_in ic_inx pos;
> (Iovalue.input ic_inx : array dsk_istr)
> }
> else (* compatibility *)
>
> where:
>
> - fname_inx_acc = "/var/lib/geneweb/test.gwb/names.acc"
> - size of fname_inx_acc = 131064
> - Iovalue.sizeof_long * (table_size + i) = 131864
>
> Obviously, Iovalue.sizeof_long is too big. Dividing it by two makes the
> original query work (it seems). But I cannot give any guarantee that it
> doesn't break something else.
>
> Has the upstream author been contacted about this issue?
Not until now (we hadn't enough information, imho).
As you guys did a lot of good investigation, I think it is now OK to
get in touch with Daniel about this bug.
Daniel, the whole story is at:
http://bugs.debian.org/557553
signature.asc
Description: Digital signature
Re: Bug#557553: geneweb: Search and navigaition fails
Quoting Daniel de Rauglaudre (daniel.de_rauglau...@inria.fr): > Hi, > > > > Obviously, Iovalue.sizeof_long is too big. Dividing it by two makes the > > > original query work (it seems). But I cannot give any guarantee that it > > > doesn't break something else. > > Which version (ident src/iovalue.ml)? I indeed found bugs for 64 bits > architectures. In src/iovalue.ml, "sizeof_long" is now defined as (line > 14 of that file): >value sizeof_long = Sys.word_size / 8; The overall version is a CVS snapshot as of Oct. 31 2009. iovalue.ml is: (* $Id: iovalue.ml,v 5.9 2009-03-10 21:10:29 ddr Exp $ *) I bet that I'll need to do another CVS snapshot..:-) signature.asc Description: Digital signature
Really need help with geneweb
tags 557553 help thanks Dear Ocaml maintainers, I maintain geneweb for a very long time. Indeed for as long as I am a DD and even more Still, my clues in Ocaml are close to zeroand #557553 can't be solved by myself alone. It makes geneweb unusable on amd64 and, I guess, on any 64-bit architecture. Is there any chance that one of you takes some time to look at this package and this code to figure out what can be done and, hopefully, propose a patch? I think that the bug history has all needed information. Many thanks, inn advance, for your help -- signature.asc Description: Digital signature
Re: Bug#603580: geneweb: armel: stripped binaries are broken
Quoting Hans-Jakob Holtz (hans-jakob.ho...@gmxpro.net): > Package: geneweb > Version: 5.02~cvs20091031-7 > Severity: normal > > *** Please type your report below this line *** > On armel, the binaries (gwd, gwu, gwc, gwsetup, gwb2ged) are all identical > and non-working. They only contain the OCaml VM, but no bytecode. > > The problem is not present on i386, due to native executables being generated > there, which are safe to strip. > Building with DEB_BUILD_OPTIONS=nostrip makes it work on armel. > > Probably, other architectures without a native OCaml compiler are concerned > as well. Hello, Sorry for leaving this unanswered for too long Would the (untested) patch be the right solution? I have few experience with this so I may be entirely wrong. To Ocaml specialists : besides your advice on the above, is it, in your opinion, normal that dh_strip makes bytecode executable useless? --- rules 2011-01-10 18:49:37.950907929 +0100 +++ rules.new 2011-01-10 18:49:18.525876303 +0100 @@ -14,6 +14,9 @@ else echo "out";\ fi) endif +ifeq ($(DEB_HOST_ARCH),armel) + DEB_BUILD_OPTIONS=nostrip +endif configure: dh_testdir signature.asc Description: Digital signature
Re: Bug#603580: geneweb: armel: stripped binaries are broken
severity 603580 serious thanks Quoting Stéphane Glondu (glo...@debian.org): > Le 10/01/2011 18:52, Christian PERRIER a écrit : > > To Ocaml specialists : besides your advice on the above, is it, in > > your opinion, normal that dh_strip makes bytecode executable useless? > > It depends on what you mean by "normal". It is a known behaviour, and my > personal feeling is that it is not normal. But upstream disagrees and > recommends that bytecode executables should not be built with the > -custom option instead, which is what we adopted as a policy in the > Debian OCaml team. However, it is not trivial to build a bytecode > executable without -custom when it contains C parts (I don't know about > geneweb specifically). See #256900. So, in short, this bug is RC as geneweb doesn't work on all arches with no native compiler. I should indeed have raised this severity earlier. I'm currently building packages with Hans-Jakob patch. signature.asc Description: Digital signature
Re: Bug#603580: geneweb: armel: stripped binaries are broken
Hans-Jakob, I would be very interested if you can formally confirm that the latest uploaded version of geneweb (-8) does fix that problem on armel. Many thanks in advance (and thanks for your help fixing this). signature.asc Description: Digital signature
