Re: some wget patches against beta3
On Tuesday 07 of October 2003 12:08, Hrvoje Niksic wrote: Thanks! btw. looking into test4 I see that autoconf conception is used in weird way. Normally aclocal.m4 is autogenerated by aclocal command (and it includes sources of macros from /usr/share/autoconf/autoconf/*.m4 and from local acinclude.m4). You are seem to put all macros (even local macros!) inside of aclocal.m4. This is bad because it doesn't allow to regenerate autoconf/aclocal stuff in case when it's needed. aclocal command will overwrite aclocal.m4 and all local macros will be lost. We at PLD are right now patching wget to move all local macros into acinclude.m4 but it would be better if that was done properly at wget maintainers level :) ps. I see that beta5 is there so time to look into this one... argh, same things as in test4 -- Arkadiusz MikiewiczCS at FoE, Wroclaw University of Technology arekm.pld-linux.org AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PLD/Linux
Re: some wget patches against beta3
Arkadiusz Miskiewicz [EMAIL PROTECTED] writes: On Tuesday 07 of October 2003 12:08, Hrvoje Niksic wrote: Thanks! btw. looking into test4 I see that autoconf conception is used in weird way. Normally aclocal.m4 is autogenerated by aclocal command Normally only if you're also using Automake. Wget doesn't use Automake and therefore has no use for `aclocal'. You are seem to put all macros (even local macros!) inside of aclocal.m4. Yes, local macros are in aclocal.m4 -- that's how it got its name. Autoconf manual says: To create a `configure' script with Autoconf, you need to write an Autoconf input file `configure.ac' (or `configure.in') and run `autoconf' on it. If you write your own feature tests to supplement those that come with Autoconf, you might also write files called `aclocal.m4' and `acsite.m4'. Then, later: Those files [`aclocal.m4' and `acsite.m4'] can contain your site's or the package's own Autoconf macro definitions. `acinclude.m4' is not even mentioned, so I must assume it's another Automake thing. This is bad because it doesn't allow to regenerate autoconf/aclocal The macros in aclocal.m4 are not autogenerated, therefore there is no need for regeneration. Am I missing something? We at PLD are right now patching wget to move all local macros into acinclude.m4 but it would be better if that was done properly at wget maintainers level :) Could you explain the motivation behind the move from aclocal.m4 to acinclude.m4?
Re: some wget patches against beta3
[EMAIL PROTECTED] (Martin v. Löwis) writes:
Why do you think the scheme is narrow-minded?
Because 1.9-beta3 seems to be a problem.
VERSION = ('[.0-9]+-?b[0-9]+'
'|[.0-9]+-?dev[0-9]+'
'|[.0-9]+-?pre[0-9]+'
'|[.0-9]+-?rel[0-9]+'
'|[.0-9]+[a-z]?'
'|[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]')
But that's narrow. Why support 1.9-b3, but not 1.9-beta3 or
1.9-alpha3, or 1.9-rc10? Those and similar version schemes are in
wide use.
That's really bad. But what's even worse is that something or
someone silently changed beta3 to b3 in the POT, and then failed
to perform the same change for my translation, which caused it to
get dropped without notice.
Nothing should get dropped without a notice. [...]
I now understand that this could have been an exception due to the
outage. But that's how it happened. I sent the translation -- twice
-- and it got dropped. Karl told me to resend the translation with a
1.9-b3 version (which I'd never heard of before), so I naturally
assumed that the submission had been dropped because of version.
Now, since UMontreal has changed the translation@ alias, it might be
that some messages were lost during the outage; this is unfortunate,
but difficult to correct, as we cannot find out which messages might
have lost. Fortunately, most translators know to get a message back
from the robot for all submissions, so if they don't get one, they
resend.
Note that I did resend, but to no avail. My first attempt contained a
MIME attachment, which I then found out the robot didn't understand.
My second attempt was from po-mode, which should have produced a valid
message, except for the version.
Re: some wget patches against beta3
[EMAIL PROTECTED] (Martin v. Löwis) writes:
Hrvoje Niksic [EMAIL PROTECTED] writes:
VERSION = ('[.0-9]+-?b[0-9]+'
'|[.0-9]+-?dev[0-9]+'
'|[.0-9]+-?pre[0-9]+'
'|[.0-9]+-?rel[0-9]+'
'|[.0-9]+[a-z]?'
'|[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]')
But that's narrow. Why support 1.9-b3, but not 1.9-beta3 or
1.9-alpha3, or 1.9-rc10? Those and similar version schemes are in
wide use.
Are you requesting the addition of these three formats?
Yes, please.
To be clear: it would be ideal if the Robot didn't care about
versioning at all. But if it really has to, then it should support
versioning schemes in wide use.
Re: some wget patches against beta3
Hrvoje Niksic [EMAIL PROTECTED] writes: As for the Polish translation, translations are normally handled through the Translation Project. The TP robot is currently down, but I assume it will be back up soon, and then we'll submit the POT file and update the translations /en masse/. It took a little bit longer than expected but now, the robot is up and running again. This morning (CET) I installed b3 for translation.
Re: some wget patches against beta3
Karl Eichwalder [EMAIL PROTECTED] writes: Hrvoje Niksic [EMAIL PROTECTED] writes: As for the Polish translation, translations are normally handled through the Translation Project. The TP robot is currently down, but I assume it will be back up soon, and then we'll submit the POT file and update the translations /en masse/. It took a little bit longer than expected but now, the robot is up and running again. This morning (CET) I installed b3 for translation. However, http://www2.iro.umontreal.ca/~gnutra/registry.cgi?domain=wget still shows `wget-1.8.2.pot' to be the current template for [the] domain. Also, my Croatian translation of 1.9 doesn't seem to have made it in. Is that expected?
Re: some wget patches against beta3
Karl Eichwalder [EMAIL PROTECTED] writes: Also, my Croatian translation of 1.9 doesn't seem to have made it in. Is that expected? Unfortunately, yes. Will you please resubmit it with the subject line updated (IIRC, it's now): TP-Robot wget-1.9-b3.hr.po I'm not sure what b3 is, but the version in the POT file was supposed to be beta3. Was there a misunderstanding somewhere along the line?
Re: some wget patches against beta3
Karl Eichwalder [EMAIL PROTECTED] writes: Hrvoje Niksic [EMAIL PROTECTED] writes: I'm not sure what b3 is, but the version in the POT file was supposed to be beta3. Was there a misunderstanding somewhere along the line? Yes, the robot does not like beta3 as part of the version string. b3 or pre3 are okay. Ouch. Why does the robot care about version names at all?
Re: some wget patches against beta3
Karl Eichwalder [EMAIL PROTECTED] writes: Hrvoje Niksic [EMAIL PROTECTED] writes: Ouch. Why does the robot care about version names at all? It must know about the sequences; this is important for merging issues. IIRC, we have at least these sequences supported by the robot: 1.2 - 1.2.1 - 1.2.2 - 1.3 etc. 1.2 - 1.2a - 1.2b - 1.3 1.2 - 1.3-pre1 - 1.3-pre2 - 1.3 1.2 - 1.3-b1 - 1.3-b2 - 1.3 Thanks for the clarification, Karl. But as a maintainer of a project that tries to use the robot, I must say that I'm not happy about this. If the robot absolutely must be able to collate versions, then it should be smarter about it and support a larger array of formats in use out there. See `dpkg' for an example of how it can be done, although the TP robot certainly doesn't need to do all that `dpkg' does. This way, unless I'm missing something, the robot seems to be in the position to dictate its very narrow-minded versioning scheme to the projects that would only like to use it (the robot). That's really bad. But what's even worse is that something or someone silently changed beta3 to b3 in the POT, and then failed to perform the same change for my translation, which caused it to get dropped without notice. Returning an error that says your version number is unparsable to this piece of software, you must use one of ... instead would be more correct in the long run. Is the robot written in Python? Would you consider it for inclusion if I donated a function that performed the comparison more fully (provided, of course, that the code meets your standards of quality)?
Re: some wget patches against beta3
Karl Eichwalder [EMAIL PROTECTED] writes: I guess, you as the wget maintainer switched from something supported to the unsupported betaX scheme and now we have something to talk about ;) I had no idea that something as usual as betaX was unsupported. In fact, I believe that bX was added when Francois saw me using it in Wget. :-) Using something different then exactly wget-1.9-b3.de.po will confuse the robot sigh Returning an error that says your version number is unparsable to this piece of software, you must use one of ... instead would be more correct in the long run. Sure. You should have receive a message like this, didn't you? I didn't. Maybe it was an artifact of robot not having worked at the time, though.
some wget patches against beta3
Hi, Here is few patches against test3: http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/wget-ac.patch?rev=1.4 (some autoconf 2.5x things) http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/wget-pl.patch?rev=1.3 (Polish translation update) -- Arkadiusz MikiewiczCS at FoE, Wroclaw University of Technology arekm.pld-linux.org AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PLD/Linux
Re: some wget patches against beta3
Thanks for the contribution. Note that a slightly more correct place to send the patch is the [EMAIL PROTECTED] list, followed by people with a keener interest in development. Also, you should send at least a short explanation of what each patch is supposed to do and why one should apply it. (Except in the case of really short, self-explanatory patches, of course.) As for the Polish translation, translations are normally handled through the Translation Project. The TP robot is currently down, but I assume it will be back up soon, and then we'll submit the POT file and update the translations /en masse/.
