Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
Max, no - you have not disqualified yourself in my eyes. And therefore, you should be the new doxygen owner/maintainer if you want it that badly. I also think that we should put this issue finally to rest, stop pouting and get on with life! greets, H. Max Bowsher wrote: Christopher Faylor wrote: Otherwise, MaxB has disqualified himself from doxygen package maintainership, I would to appeal this, please, because I do not believe it is fair to censure me for a misunderstanding that I have explained and apologized for. The fact that a few words of mild intention can be misinterpreted and seed an accidental high tension mess has been amply well demonstrated on the cygwin list recently, in the CGF/GRVS thread. Max.
Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
Chris, Corinna Max, thanks but no thanks. I had a real rough start with this, which utterly discouraged me and dampened my enthusiasm to maintain anything at this time considerably! So please consider doxygen and bash to be up again for grabs! As far as I am concerned, can't you just let Max be doxygen maintainer if he still wants to? The least I want is to seed trouble among the cygwin core team and long-time maintainers such as Max. H. Christopher Faylor wrote: On Sat, Apr 23, 2005 at 12:35:19AM +0100, Max Bowsher wrote: Hans W. Horn wrote: Alright, Max Bowsher wrote: No, still wrong. You didn't read what I said carefully enough. You *need* to understand: Filenames are expected to be EXACTLY: NAME-VERSION-RELEASE.tar.bz2 NAME-VERSION-RELEASE-src.tar.bz2 I guess I never appreciated the subtle naming convention used for cygwin packages. Honestly, my impression was that names go all over the map. Fixed (I think). +++ doxygen_1.4.2-20050410/doc/language.doc +++ doxygen_1.4.2-20050410/doc/translator_report.txt +++ doxygen_1.4.2-20050410/examples/example.tag These files are touched during a 'make install_docs'. Excluded offending diffs from patch. Having got the superficial naming problems out of the way, I took a closer look at the source packaging. There were many issues - the most serious being that the source package did not even contain the Cygwin specific readme at all - and many minor deficiencies related to using a home-grown build script, rather than the tried-and-true cygwin template. I am sorry, but the conclusion I came to was that it would be less effort for me to produce my own packages of doxygen, based on the the generic-build-script, than to assist in getting these packages up to a good-to-go status. Accordingly, I hereby ITP doxygen myself: Setup.exe installation site: http://unicorn.robinson.cam.ac.uk/~mob22/cygdoxygen/ I've waited several days to respond to this because I wanted to make sure that I was in the proper emotional state and didn't just fire off a knee-jerk reaction. Nevertheless, I remain appalled by this turn of events. I saw nothing in Hans' email which indicated that he's unwilling to be cooperative about packaging problems so I see no reason to pull the package from him. Hans is not the first person to have to go through a moderate amount of pain before getting the packaging right and if the biggest complaint of his source packaging is that it doesn't contain the cygwin README, then that is not a big deal. I don't know how to resolve this situation but I do know for sure that neither Corinna nor I are going to reward someone by making them a package maintainer after essentially publicly insulting another volunteer. Hans, this is still yours if you want it. Otherwise, MaxB has disqualified himself from doxygen package maintainership, so I guess we're in the market for a maintainer again. cgf
Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
Max Bowsher wrote: Hans W. Horn wrote: Max Bowsher wrote: ... Having got the superficial naming problems out of the way, I took a closer look at the source packaging. Superficial? In your earlier complaints you made it sound as if those naming issues were of utmost importance! There were many issues - the most serious being that the source package did not even contain the Cygwin specific readme at all - and... hear - hear (you didn't look, did you?)! Yes, I did. And just to be sure, I used grep. It was not there. Interesting! You did a grep on a compressed tarball? Or on a directory tree? Quite unconventional. I would use 'find'. As in: cd /usr find ./ -name doxygen*README -print ./share/doc/Cygwin/doxygen-1.4.2_20050410-1.README many minor deficiencies related to using a home-grown build script, rather than the tried-and-true cygwin template. Yup! Guilty as charged! typical NIH syndrom! NIH? Not Invented Here. Probably doesn't count. Has no cygwin trademark! I am sorry, but the conclusion I came to was that it would be less effort for me to produce my own packages of doxygen, based on the the generic-build-script, than to assist in getting these packages up to a good-to-go status. As I see it: the last version of the package I have submitted was as much or little conformant to the cygwin guidelines as the package it was meant to supercede, or 50% of all the other cygwin packages on the market today. All Cygwin package maintainers work to the set of guidelines that the project has designed for itself, and which are posted on the website. If you desire to help, but lack the time or inclination to meet the guidelines the project has defined for itself, ... and which are being modified on the fly, see http://cygwin.com/ml/cygwin-apps/2005-04/msg00063.html ...then you will discover that whilst your desire to help is appreciated ... Are you sure you mean that? ..., you actual offerings may not actually be helpful to the project. This is a simple fact. If it angers you... there is nothing I can do about that. I'm sure you wouldn't! But that's not what angers me; it is rather arrogance and pretence that pushes my button. In any case : this is not a competition for maintainership - you may keep it all for yourself! And I'm out for good!
Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
Max Bowsher wrote: ... Having got the superficial naming problems out of the way, I took a closer look at the source packaging. There were many issues - the most serious being that the source package did not even contain the Cygwin specific readme at all - and hear - hear (you didn't look, did you?)! many minor deficiencies related to using a home-grown build script, rather than the tried-and-true cygwin template. typical NIH syndrom! I am sorry, but the conclusion I came to was that it would be less effort for me to produce my own packages of doxygen, based on the the generic-build-script, than to assist in getting these packages up to a good-to-go status. You're so full of it! But, honestly, I saw this coming! I'd say - why don't you just shove it! And seriously, I really can't remember why I even thought it would be a good thing to offer my services to maintain anything for the cygwin crowd! That memory has gotten somewhat hazy! Bye now! H.
Re: maintaining bash
I hereby withdraw my voluntary offer as bash maintainer! H.
Please upload: doxygen-1.4.2_20050410-1 (n'th take)
Alright, Max Bowsher wrote: No, still wrong. You didn't read what I said carefully enough. You *need* to understand: Filenames are expected to be EXACTLY: NAME-VERSION-RELEASE.tar.bz2 NAME-VERSION-RELEASE-src.tar.bz2 I guess I never appreciated the subtle naming convention used for cygwin packages. Honestly, my impression was that names go all over the map. Fixed (I think). +++ doxygen_1.4.2-20050410/doc/language.doc +++ doxygen_1.4.2-20050410/doc/translator_report.txt +++ doxygen_1.4.2-20050410/examples/example.tag These files are touched during a 'make install_docs'. Excluded offending diffs from patch. Same url (http://www.smithii.com/files/cygwin/hans/): -rw-r--r-- 1 32237 ross 2273644 Apr 19 11:58 doxygen-1.4.2_20050410-1-src.tar.bz2 -rw-r--r-- 1 32237 ross 1999837 Apr 19 11:58 doxygen-1.4.2_20050410-1.tar.bz2 -rw-r--r-- 1 32237 ross 183 Apr 19 11:58 md5.sum -rw-r--r-- 1 32237 ross 353 Apr 19 11:58 setup.hint H.
Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take)
It's only subtle, until you've digested that in this notation RELEASE is a cygwin version attribute and VERSION is an upstream version attribute (which on its own may already use a similar naming convention, such as doxygen-1.4.2-20050410). Confused the hell out of me! H. Christopher Faylor wrote: On Tue, Apr 19, 2005 at 10:30:12AM -0700, Hans W. Horn wrote: Max Bowsher wrote: No, still wrong. You didn't read what I said carefully enough. You *need* to understand: Filenames are expected to be EXACTLY: NAME-VERSION-RELEASE.tar.bz2 NAME-VERSION-RELEASE-src.tar.bz2 I guess I never appreciated the subtle naming convention used for cygwin packages. Honestly, my impression was that names go all over the map. NAME-VERSION-RELEASE is subtle? That's interesting. cgf
Please upload: doxygen v1.4.2-20050410 (3nd take)
I've uploaded another cut of doxygen v142 src binary packages to http://www.smithii.com/files/cygwin/hans/, addressing more concerns/suggestions raised by Max Bowsher. In particular: 1. removing pdf manual 2. including upstream source tarball 3. package naming issues -rw-r--r-- 1 32237 ross 2276844 Apr 15 11:34 doxygen_1.4.2-20050410-src.tar.bz2 -rw-r--r-- 1 32237 ross 2000493 Apr 15 11:35 doxygen_1.4.2-20050410.tar.bz2 -rw-r--r-- 1 32237 ross 179 Apr 15 11:35 md5.sum -rw-r--r-- 1 32237 ross 351 Apr 15 11:35 setup.hint Does that do? H.
Re: Please upload: doxygen v1.4.2-20050410 (3nd take)
Max, Max Bowsher wrote: Hans W. Horn wrote: I've uploaded another cut of doxygen v142 src binary packages to http://www.smithii.com/files/cygwin/hans/, addressing more concerns/suggestions raised by Max Bowsher. In particular: 1. removing pdf manual 2. including upstream source tarball 3. package naming issues -rw-r--r-- 1 32237 ross 2276844 Apr 15 11:34 doxygen_1.4.2-20050410-src.tar.bz2 -rw-r--r-- 1 32237 ross 2000493 Apr 15 11:35 doxygen_1.4.2-20050410.tar.bz2 -rw-r--r-- 1 32237 ross 179 Apr 15 11:35 md5.sum -rw-r--r-- 1 32237 ross 351 Apr 15 11:35 setup.hint Does that do? Package naming still incorrect. It should be: doxygen-1.4.2_20050410-1.tar.bz2 doxygen-1.4.2_20050410-1-src.tar.bz2 Fixed. Also, please could you briefly describe the purpose and origin of the following parts of the patch: +++ doxygen_1.4.2-20050410/addon/doxywizard/version.cpp 1969-12-31 16:00:00.0 -0800 addon/doxywizard/version.cpp is created during the build and removed during a 'make distclean'. The upstream version I was diffing against, must not have been made 'distclean'. I haved removed the offending file from the upstream version I am diffing against! +++ doxygen_1.4.2-20050410/doc/language.doc 2005-04-12 08:19:02.941256000 -0700 +++ doxygen_1.4.2-20050410/doc/translator_report.txt 2005-04-12 08:19:05.404798400 -0700 +++ doxygen_1.4.2-20050410/examples/example.tag 2005-04-15 08:12:16.622246400 -0700 These files are touched during a 'make install_docs'. diffs seem to be meaningless! Is there a way to exclude them from the patch file (I mean automatically)? The Cygwin-specific readme should be wrapped to remain within 80 columns. Fixed! But, please, take a look at doxygen-1.2.18.README and tell me how many chars per line you see! And, by the way, the previous doxygen-1.2.18 version did ship with a pdf version of its manual Re-uploaded! -rw-r--r-- 1 32237 ross 2276504 Apr 15 19:45 doxygen-1.4.2_20050410-src.tar.bz2 -rw-r--r-- 1 32237 ross 2000743 Apr 15 19:47 doxygen-1.4.2_20050410.tar.bz2 -rw-r--r-- 1 32237 ross 179 Apr 15 19:47 md5.sum -rw-r--r-- 1 32237 ross 351 Apr 15 19:47 setup.hint Does that do? H.
Re: Please upload: doxygen v1.4.2-20050410 (2nd take)
Max,
I found the origin of the mysterious rendering problem I'd referred to.
My computer is missing a font specified in doxygen.css:
.fragment {
font-family: Fixed, monospace;
font-size: 95%;
}
The doxygen pdf manual will go, as soon as I have found that friggen font
somewhere!
H.
Max Bowsher wrote:
Hans W. Horn wrote:
Hi Max,
Max Bowsher wrote:
One further suggestion: I think it would be appropriate to include
only the html version of the manual. Including the PDF format too
substantially increases the size of the package, for no real gain -
it's just duplication.
Actually, I just noticed that there are rendering problems with the
doxygen
html pages for several browsers (IE, firefox) which don't occur with
the corresponing pdf.
So for the time being I'd prefer to keep the pdf!
I also noticed the same rendering problems with the doxygen html
pages on the web and posted about my observations on
gmane.text.doxygen.general.
I saw - however, I do not see the rendering problems displayed in your
screenshot in any of IE, Mozilla, or Firefox, so I am rather less
convinced about keeping the PDF.
Max.
Re: Please upload: doxygen v1.4.2-20050410 (2nd take)
Hi Max, Max Bowsher wrote: Thanks! Some further issues: In setup.hint, the first letter of an sdesc is typically capitalized - just run setup.exe and look at the descriptions visible in the package picker to see what other packages do. Will fix at the next turn of the crank (if that's ok)! The naming of the packages has a problem: Cygwin packages are NAME-VERSION-RELEASE, of which only NAME may further - characters. Since the upstream package contains a - within it's version, changing this to a _ would be a suitable workaround. Thus, the binary package would be named: doxygen-1.4.2_20050410-1.tar.bz2. Question: is the -1 at the end required? What is it supposed to mean? The release# under cygwin? Anyways, I will change first '-' to '_' at the next turn of the crank! A source package should be labelled with the addition of -src, not _src. Ditto. Thanks for accomodating my request that the original upstream source be included. It is more usual to include the upstream tarball itself, though. Despite this being only an intermediate snapshot, it is available as a tarball: http://www-kp3.gsi.de/~kp3softd/doxygen/. Ditto My name has no c in it. :-) Oops. One further suggestion: I think it would be appropriate to include only the html version of the manual. Including the PDF format too substantially increases the size of the package, for no real gain - it's just duplication. I never liked pdf docs, if I can use html docs instead. Will drop pdf docs at the next turn of the crank! H.
Re: Please upload: doxygen v1.4.2-20050410 (2nd take)
Hi Max, Max Bowsher wrote: One further suggestion: I think it would be appropriate to include only the html version of the manual. Including the PDF format too substantially increases the size of the package, for no real gain - it's just duplication. Actually, I just noticed that there are rendering problems with the doxygen html pages for several browsers (IE, firefox) which don't occur with the corresponing pdf. So for the time being I'd prefer to keep the pdf! I also noticed the same rendering problems with the doxygen html pages on the web and posted about my observations on gmane.text.doxygen.general. H.
Please upload: doxygen v1.4.2-20050410
Please upload the latest doxygen release for cygwin (v1.4.2-20050410) Binaries, sources setup.hint files are located at http://www.geocities.com/hannes_horn/cygwin/doxygen/ -rw-rw-rw- 1 hanshorn Power Users 1823811 Apr 11 23:44 doxygen-1.4.2-20050410-src.tar.bz2 -rw-rw-rw- 1 hanshorn Power Users 1474000 Apr 11 23:43 doxygen-1.4.2-20050410.tar.bz2 -rwx--+ 1 hanshorn Power Users 351 Apr 11 08:26 setup.hint Since yahoo free webhosting doesn't allow files with the .bz2 extension, I changed the extension of the package files to tgz. Just save these files back as .bz2. Same with setup.hint. Here I simply appended .html; just save without .html. Since this is my first contribution of this kind, please bear with me if I didn't get it all right off the bat. Hans
Re: doxygen status
Chris, btw. quoting http://cygwin.com/setup.html: Submitting a package ... 7. So you've got a package you want to submit. Follow the following checklist before emailing cygwin-apps@cygwin.com and you'll almost certainly save time. Announce on cygwin-apps@cygwin.com that you have the package ready for uploading. Add the URLs to all package files to your mail or, if you can't provide it on a web page, someone with upload privileges will contact you to get access to the package files to upload them to sourceware.org for you. If the above is not true, then it should be corrected, shouldn't it? H. Christopher Faylor wrote: On Mon, Apr 11, 2005 at 10:30:43AM -0700, Hans W. Horn wrote: I've packaged tested the latest doxygen release (1.4.2-20050410) after applying Max' latest patch (http://bugzilla.gnome.org/show_bug.cgi?id=300204). Since this is my first package contribution: how do I go about uploading? I currently don't have a webserver where I can stage the packages. That's rather a show stopper. We usually use the pull model for retrieving packages, which means you need to have a web site. Can't you use one of the free web hosting facilities? cgf
Re: doxygen status
Chris, Christopher Faylor wrote: ...We usually use the pull model for retrieving packages, which means you need to have a web site. Can't you use one of the free web hosting facilities? I already went through two free hosting providers. The first one I tried (netfirms) had a limit of 256k on downloads and wouldn't provide directory listings. The second one I tried (Yahoo / geocities) does not allow bz2 and .hint files to be stored. Max finds it nasty just to rename extensions. Which free ones do the experts recommend? H.
Re: Please upload: doxygen v1.4.2-20050410
Hi Brian Max, Brian Dessent wrote: The binaries in your package are still in /usr/local/bin. They need to go in /usr/bin. In http://cygwin.com/ml/cygwin-apps/2005-03/msg00067.html, you only mentioned the manpages that would need to be in a new home. Will fix. Also, you included a manpage for doxywizard but there's no binary for it. Will fix. It's also customary to include a Cygwin-specific README that unpacks into /usr/share/doc/Cygwin/package-x.y-z.README that contains basic notes about the port, who the maintainer is, and where the upstream homepage is. Will add. You didn't include any of the html documentation as the previous package did. That's of course your choice as maintainer but I find that the manpage is really pretty lacking, it hardly says anything at all. What an oversight of mine. Will add. Max Bowscher wrote: I think preserving the original distibution's tarball untouched is a good thing to do. In the next round I'll provide the original sources + patch, rather than the patched sources. I have pulled http://www.geocities.com/hannes_horn/cygwin/doxygen/. A new announcement is forthcoming. H.
Please upload: doxygen v1.4.2-20050410 (2nd take)
Please upload the latest doxygen release for cygwin (v1.4.2-20050410) Binaries, sources setup.hint files are located at http://www.smithii.com/files/cygwin/hans/ (thanks to Ross Smith II for providing web space). -rw-r--r-- 1 32237 ross 2558933 Apr 12 20:18 doxygen-1.4.2-20050410.tar.bz2 -rw-r--r-- 1 32237 ross 1824834 Apr 12 20:19 doxygen-1.4.2-20050410_src.tar.bz2 -rw-r--r-- 1 32237 ross 179 Apr 12 20:22 md5.sum -rw-r--r-- 1 32237 ross 351 Apr 12 20:19 setup.hint Since this is the 2nd attempt of my first contribution of this kind, please bear with me if I still didn't get it all right. I honored various complaints by Brian Dessent and Max Bowscher. Hans
Re: doxygen status
heard anything from the doxygen maintainer? R.I.P? On Mar 24 09:02, Hans Horn wrote: Group, I noticed that the vintage of doxygen that ships with cygwin (v1.2.18) is more than two years old. The current version of doxygen (1.4.1-20050315) builds ootb and appears to be functioning properly; I ran it on a mid-size C++ source tree and on a rather large Java source tree. When doing the latter, I noticed that the current vintage is almost infinitely faster than the one that is shipping with cygwin. The question is, is there a maintainer for doxygen, and if so, is she still alive and willing. If not, I'd like to step up to the plate and offer my services as new doxygen maintainer. Dunno if our Doxygen maintainer is still listening, but I've Cc'd the cygwin-apps list. Ryunosuke, are you still somewhere around? Are you still interested in maintaining doxygen? Hans, further discussion should take place on cygwin-apps. Thanks for your offer, Corinna
Re: doxygen status
Will do! thanks, Max. Max Bowsher wrote: I've just filed this upstream: http://bugzilla.gnome.org/show_bug.cgi?id=300204 [PATCH] Doxygen disobeys Cygwin 'text/binary mount mode' please consider including until it gets applied upstream. Also note that 1.4.2 has a nasty regression in member group handling. Locally, I've fallen back to 1.4.1. v1.4.2 has also fixed various problems, that caused me to move to 1.4.2. H.
Re: doxygen status
I've packaged tested the latest doxygen release (1.4.2-20050410) after applying Max' latest patch (http://bugzilla.gnome.org/show_bug.cgi?id=300204). Since this is my first package contribution: how do I go about uploading? I currently don't have a webserver where I can stage the packages. Corinna Vinschen wrote: On Apr 11 07:12, Hans W. Horn wrote: heard anything from the doxygen maintainer? R.I.P? Nope. Go ahead. Corinna
Re: doxygen status
Max, Max Bowsher wrote: BTW, which platform did you tell doxygen's configure to use? I've been building with linux-g++. I was using win32-g++. Also, did you build with the internal libpng, or use Cygwin's system libpng? I used the system libpng (just removed the make -C libpng command from the makefile). I did always build link doxygen with its own png (libpng1.0). Hm, interesting, cygwin's default png is libpng12, which infact is used in the include path for the compilation of doxygen sources, (e.g. g++ -c -fno-exceptions -fno-rtti -O -I../qtools -I/usr/include/libpng12 -I../libmd5 -o ../objects/ce_lex.o ce_lex.cpp). I just re-built doxygen w/o its built-in png and ran a few documentation projects. The results seem to indicate that the png version used doesn't matter. H.
Re: doxygen status
Hi Max, I take that you are suggesting to configure doxygen with linux-g++. Will do, as well as builing using cygwin's libpng. greets, H. Max Bowsher wrote: Hans W. Horn wrote: Max, Max Bowsher wrote: BTW, which platform did you tell doxygen's configure to use? I've been building with linux-g++. I was using win32-g++. Ah. Then my patch certainly isn't having any effect at all, since qfile_unix.cpp isn't even being compiled. I've no specific points in favour of either option, just a general observation that when special-case windows file handling code is used, it often ends up going behind Cygwin's back, and making the program act more Windows-ish than a Cygwin user expects. Plus the win32-g++ mode has explicit -D__CYGWIN__ options thrown all over the place, when Cygwin compilers have been predefining that symbol for absolutely ages, suggesting that might be somewhat bitrotted. Also, did you build with the internal libpng, or use Cygwin's system libpng? I used the system libpng (just removed the make -C libpng command from the makefile). I did always build link doxygen with its own png (libpng1.0). Hm, interesting, cygwin's default png is libpng12, which infact is used in the include path for the compilation of doxygen sources, (e.g. g++ -c -fno-exceptions -fno-rtti -O -I../qtools -I/usr/include/libpng12 -I../libmd5 -o ../objects/ce_lex.o ce_lex.cpp). I just re-built doxygen w/o its built-in png and ran a few documentation projects. The results seem to indicate that the png version used doesn't matter. This is all I've been using to build with the system png library: Index: configure === RCS file: /u/kp3softd/cvsroot/configure,v retrieving revision 1.209 diff -u -p -r1.209 configure --- configure 10 Apr 2005 18:36:48 - 1.209 +++ configure 11 Apr 2005 21:19:31 - @@ -483,7 +483,6 @@ EOF echo $DST echo all: src/version.cpp $DST echo \$(MAKE) -C qtools $DST - echo \$(MAKE) -C libpng $DST echo \$(MAKE) -C libmd5 $DST echo \$(MAKE) -C src $DST if test $f_wizard = YES; then It seems a little wasteful for doxygen to carry around its own version of the code when there's already a package available. Max.
Re: maintaining bash
Corinna Igor, Urgh! Bold hint: ./configure --prefix=/usr I just (con-)figured that out myself. Thx anyways! How do I go about Pierre's pid patch? You'll need to see exactly what it changes in the 2.05 sources, find and modify the corresponding places in the 3.0 sources, and then (the hardest part) test that the fix actually works. This mysterious patch of Pierre: is it in that half-a-ton patch file that comes with the bash-2.05b-17 sources? If yes, hasn't anybody tried to get this patch back into bash mainstream? H.
Re: maintaining bash
Thanks Brian, Brian Dessent wrote: Hans W. Horn wrote: This mysterious patch of Pierre: is it in that half-a-ton patch file that comes with the bash-2.05b-17 sources? If yes, hasn't anybody tried to get this patch back into bash mainstream? No, this is Pierre's patch: http://marc.theaimsgroup.com/?l=cygwinm=109867031200979w=2 This helps a lot! By working my way thru 3way-comparison of 2.05unpatched vs 2.05patched vs 3.0patched, I saw that many (but not all) of Pierre's patches must have made it back into bash mainstream. For some sources, however (in particular in jobs.c and subst.c) the changes from 2.05patched vs 3.0patched (also from 2.05patched vs 3.0unpatched) are pervasive. In fact, so pervasive, that I don't feel that I have enough information / insider knowledge to apply the changes from 2.05patched to 3.0 myself. Would it be possible that Pierre (Pierre Humblet?) could take a look at it, please? H.
