Re: No bug tracker
On 3/23/23 13:36, Patrice Dumas wrote: There was a bugtracker at some point, but it was not so useful. On Thu, Mar 23, 2023 at 07:44:47PM +, Gavin Smith wrote: The scale of this project is also a factor here, and if it were a larger project a bug tracking system might be more useful, although I don't really have experience of this. To me that is the main factor here, no much point in such an infrastructure with such a small project. I work on some small (one person) and not so small open source projects that also have mailing lists. I like bug trackers because then I have a fairly easy way to find a bug instead of having to fish through tons of email with possibly incorrect subject lines that might be spread out over many threads to find the relevant discussion. But this also requires discipline to discuss the bugs on the tracker instead of the mailing list. And sometimes the mailing list is easier for bug discussion than a bug tracker. Hopefully someone will update the bug with links to the mailing list or summarizes the mailing list. But that means extra work. I also don't have any qualms about closing bugs as wontfix or not-a-bug, as long as I explain (briefly) why. But each project needs to do whatever works best for them
Re: No bug tracker
Gavin Smith , Thu Mar 23 2023 20:44:47
GMT+0100 (Central European Standard Time)
On Thu, Mar 23, 2023 at 05:57:58PM +0100, Bogdan wrote:
No bugtracker? Not good from a bug reporter's point of view :). I thought
all FSF projects use the same bugtracker, it would seem logical. You
probably have a good reason for not to have one, but don't you sometimes get
10 reports about the same problem? :)
Users are free to write to bug-texinfo@gnu.org with bugs. It doesn't
mean we don't care about bugs.
I didn't say you don't, I'm pretty sure you do.
Having a bug tracker doesn't mean that
the bugs will get fixed or that formally reported bugs are something
that the developers care about.
I do hope that developers care about formally reported bugs, not
only those sent to a mailing list :). Although a mailing list is a
formal report in this case.
You've likely had the experience of
submitting bugs to bug trackers and then the reports being ignored --
I know I have.
Well, maybe not ignored, but long waiting times and "Please check if
still valid" - sure.
It's a volunteer project and contributors will work on
what they themselves consider to be valuable, not what a bug tracker
orders them to.
I also find that a lot of reported bugs are questionable, and may
not really be bugs.
True.
Rather than risk pissing people off by closing
their bugs immediately as NOTABUG, WONTFIX or the like, or having the
tracker fill up with 1000s of junk bugs that will never be closed,
it's better to have a discussion on the mailing list to improve mutual
understanding of the issues involved.
Discussion - sure. Having to write "It's a feature, not a bug" for
the same issue 1000 times in 1000 e-mails separately to 1000 users may
be a bit less fun.
If there is a clear bug that doesn't get fixed, and it's likely there
are contributors with capacity to work on the issue, the best course of
action is to keep on emailing about it if you are worried it has been
forgotten about.
"Is my bug fixed yet?" every week :)
This shows some commitment on behalf of the person
reporting the bug and gives an indication it is something worth worrying
about, if the reporter has been motivated to follow it up.
True.
The scale of this project is also a factor here, and if it were a larger
project a bug tracking system might be more useful, although I don't really
have experience of this.
That may also be the deciding factor.
I don't know how it looks in Texinfo, but when there are 3 people
working on a project tightly, a mailing list may suffice (although I
see quite of a monthly volume on 'bug-texinfo').
When there are tens of people and hundreds of mails weekly, a
bugtracker may be better. Also perhaps easier to search for old bugs
and not duplicate them.
Anyway, I guess that we both have valid points and "it depends on
the project" is the right outcome of this thread. I was just
surprised, because Texinfo is rather important and I thought it would
be more "formalized" with more tools. Just asking, not criticizing :)
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
Re: No bug tracker
There was a bugtracker at some point, but it was not so useful. On Thu, Mar 23, 2023 at 07:44:47PM +, Gavin Smith wrote: > The scale of this project is also a factor here, and if it were a larger > project a bug tracking system might be more useful, although I don't really > have experience of this. To me that is the main factor here, no much point in such an infrastructure with such a small project. On large project it is important to have bug trackers to avoid bug being filled multiple time and to have someone responsible for each bug. -- Pat
Re: [PATCH] Texinfo: inconsistent behavior: cmd line vs. env
Gavin Smith , Thu Mar 23 2023 20:26:29
GMT+0100 (Central European Standard Time)
On Thu, Mar 23, 2023 at 07:25:29PM +, Gavin Smith wrote:
Here's an updated patch:
diff --git a/ChangeLog b/ChangeLog
index 92bc4d6325..2707f6bad5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2023-03-23 Gavin Smith
+
+ Make setting TEXI2DVI_BUILD_DIRECTORY equivalent to --build-dir option
+
+ * util/texi2dvi: Make setting build dir to a directory other
+ than '.' change build mode from 'local' to 'tidy' regardless of
+ whether it is given with --build-dir or setting the
+ TEXI2DVI_BUILD_DIRECTORY envvar. Report from Bogdan Drozdowski.
+
And this ChangeLog is inaccurate, of course, as '.' is not a special case
with this patch.
Right. Patching the patched patch :)
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
Re: [PATCH] Texinfo: inconsistent behavior: cmd line vs. env
Gavin Smith , Thu Mar 23 2023 20:25:27
GMT+0100 (Central European Standard Time)
On Thu, Mar 23, 2023 at 05:57:58PM +0100, Bogdan wrote:
There is still the minor question of what should happen if
TEXI2DVI_BUILD_DIRECTORY is set to '.' (the default). Since this is the
default value, it doesn't seem right that explicitly setting
TEXI2DVI_BUILD_DIRECTORY=. in the environment should change the
behaviour of texi2dvi.
I *was* thinking about this, too. On the other hand, if the user gives
"--build-dir=.", it *would* imply --tidy, even though this is the default.
The sole presence of the switch changes the behaviour.
It occured to me that we didn't have to make '.' the default value. We
can make the default value empty and avoid this as a special case. The
build_dir variable is not used that much in the program, so it is easy
to accommodate a change in default value.
Probably even better. When specifying a build directory, give an
actual value. If you want just --tidy and use the default directory
name, write just --tidy. Makes sense :).
[...]
Hence, I propose the following patch:
Here's an updated patch:
[...]
@@ -151,12 +151,7 @@ Build modes:
--tidy same as --build=tidy
-c, --clean same as --build=clean
--build-dir=DIR specify where the tidy compilation is performed;
- implies --tidy;
- defaults to TEXI2DVI_BUILD_DIRECTORY [$build_dir]
-
-The MODE specifies where the TeX compilation takes place, and, as a
-consequence, how auxiliary files are treated. The build mode can also
-be set using the environment variable TEXI2DVI_BUILD_MODE.
I suppose the first sentence in the above removed block is still
correct, so it could stay (but doesn't need to).
"Tidy compilation" sounds maybe a bit strange. But "compilation in
tidy mode" or "TeX compilation in tidy mode" are probably too long.
Maybe "tidy build"? But, I'm not insisting. The user probably knows
what this means anyway.
[Snip the rest of the patch - agreed]
Remember also about the help message:
"
--build-dir=DIR specify where the tidy compilation is performed;
implies --tidy;
defaults to TEXI2DVI_BUILD_DIRECTORY [$build_dir]
"
For some reason, it was made so that passing --build-dir implies --tidy...
But, maybe just for the non-default values, as I wrote above ("external
directories").
It's slightly more complicated than it needs to be due to the
indirection through TEXI2DVI_BUILD_DIRECTORY. I've reworded this in the
patch above.
From a user's point of view - looks fine. Generally, I have nothing against
your change.
Since I began playing with fixing Automake I'm just worried if its tests
would need to pass --tidy now, which wasn't present in the older versions,
so what do we do now to have a command line that works with all versions
(maybe except really ancient ones)?
But it seems we're always passing a directory which isn't ".", so hopefully
it will work.
In the new patch above "." is no longer a special case.
Sounds fine, thank you!
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
No bug tracker
On Thu, Mar 23, 2023 at 05:57:58PM +0100, Bogdan wrote: > No bugtracker? Not good from a bug reporter's point of view :). I thought > all FSF projects use the same bugtracker, it would seem logical. You > probably have a good reason for not to have one, but don't you sometimes get > 10 reports about the same problem? :) Users are free to write to bug-texinfo@gnu.org with bugs. It doesn't mean we don't care about bugs. Having a bug tracker doesn't mean that the bugs will get fixed or that formally reported bugs are something that the developers care about. You've likely had the experience of submitting bugs to bug trackers and then the reports being ignored -- I know I have. It's a volunteer project and contributors will work on what they themselves consider to be valuable, not what a bug tracker orders them to. I also find that a lot of reported bugs are questionable, and may not really be bugs. Rather than risk pissing people off by closing their bugs immediately as NOTABUG, WONTFIX or the like, or having the tracker fill up with 1000s of junk bugs that will never be closed, it's better to have a discussion on the mailing list to improve mutual understanding of the issues involved. If there is a clear bug that doesn't get fixed, and it's likely there are contributors with capacity to work on the issue, the best course of action is to keep on emailing about it if you are worried it has been forgotten about. This shows some commitment on behalf of the person reporting the bug and gives an indication it is something worth worrying about, if the reporter has been motivated to follow it up. The scale of this project is also a factor here, and if it were a larger project a bug tracking system might be more useful, although I don't really have experience of this.
Re: [PATCH] Texinfo: inconsistent behavior: cmd line vs. env
On Thu, Mar 23, 2023 at 07:25:29PM +, Gavin Smith wrote: > Here's an updated patch: > > diff --git a/ChangeLog b/ChangeLog > index 92bc4d6325..2707f6bad5 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,12 @@ > +2023-03-23 Gavin Smith > + > + Make setting TEXI2DVI_BUILD_DIRECTORY equivalent to --build-dir option > + > + * util/texi2dvi: Make setting build dir to a directory other > + than '.' change build mode from 'local' to 'tidy' regardless of > + whether it is given with --build-dir or setting the > + TEXI2DVI_BUILD_DIRECTORY envvar. Report from Bogdan Drozdowski. > + And this ChangeLog is inaccurate, of course, as '.' is not a special case with this patch.
Re: [PATCH] Texinfo: inconsistent behavior: cmd line vs. env
On Thu, Mar 23, 2023 at 05:57:58PM +0100, Bogdan wrote:
> > There is still the minor question of what should happen if
> > TEXI2DVI_BUILD_DIRECTORY is set to '.' (the default). Since this is the
> > default value, it doesn't seem right that explicitly setting
> > TEXI2DVI_BUILD_DIRECTORY=. in the environment should change the
> > behaviour of texi2dvi.
>
>
> I *was* thinking about this, too. On the other hand, if the user gives
> "--build-dir=.", it *would* imply --tidy, even though this is the default.
> The sole presence of the switch changes the behaviour.
It occured to me that we didn't have to make '.' the default value. We
can make the default value empty and avoid this as a special case. The
build_dir variable is not used that much in the program, so it is easy
to accommodate a change in default value.
> In other words, for consistency and no-surprises, it should be:
> --build-dir given => --tidy
> TEXI2DVI_BUILD_DIRECTORY given => --tidy
> whatever the values.
Yes, that makes the most sense. I realised this when trying to update
the help message.
> > Hence, I propose the following patch:
Here's an updated patch:
diff --git a/ChangeLog b/ChangeLog
index 92bc4d6325..2707f6bad5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2023-03-23 Gavin Smith
+
+ Make setting TEXI2DVI_BUILD_DIRECTORY equivalent to --build-dir option
+
+ * util/texi2dvi: Make setting build dir to a directory other
+ than '.' change build mode from 'local' to 'tidy' regardless of
+ whether it is given with --build-dir or setting the
+ TEXI2DVI_BUILD_DIRECTORY envvar. Report from Bogdan Drozdowski.
+
2023-03-21 Patrice Dumas
Index commands do not end paragraphs in texi2any
diff --git a/util/texi2dvi b/util/texi2dvi
index 28c53ebe44..bd4f3df9a8 100755
--- a/util/texi2dvi
+++ b/util/texi2dvi
@@ -36,7 +36,7 @@ set -e
program=`echo $0 | $SED -e 's!.*/!!'`
build_mode=${TEXI2DVI_BUILD_MODE:-local}
-build_dir=${TEXI2DVI_BUILD_DIRECTORY:-.}
+build_dir=${TEXI2DVI_BUILD_DIRECTORY:-}
orig_pwd=`pwd`
@@ -151,12 +151,7 @@ Build modes:
--tidy same as --build=tidy
-c, --clean same as --build=clean
--build-dir=DIR specify where the tidy compilation is performed;
- implies --tidy;
- defaults to TEXI2DVI_BUILD_DIRECTORY [$build_dir]
-
-The MODE specifies where the TeX compilation takes place, and, as a
-consequence, how auxiliary files are treated. The build mode can also
-be set using the environment variable TEXI2DVI_BUILD_MODE.
+ implies --tidy
Valid values of MODE are:
\`local' compile in the current directory, leaving all the auxiliary
@@ -166,6 +161,10 @@ Valid values of MODE are:
\`clean' same as \`tidy', but remove the auxiliary directory afterwards.
Every compilation therefore requires the full cycle.
+The build mode can also be set using the environment variable
+TEXI2DVI_BUILD_MODE. The build directory can also be set using
+the environment variable TEXI2DVI_BUILD_DIRECTORY.
+
The values of these environment variables are used to run the
corresponding commands, if they are set:
@@ -1694,7 +1693,7 @@ while test x"$1" != x"$arg_sep"; do
-~ ) verbose "Option -~ is obsolete: texi2dvi ignores it.";;
-b | --batch) ;; # Obsolete
--build) shift; build_mode=$1;;
- --build-dir) shift; build_dir=$1; build_mode=tidy;;
+ --build-dir) shift; build_dir=$1;;
-c | --clean) build_mode=clean;;
-D | --debug) debug=true;;
-e | -E | --expand) expand=true;;
@@ -1743,6 +1742,11 @@ done
# Pop the token
shift
+# If build_dir given, switch from --local to --tidy
+if test x"$build_dir" != x"" && test x"$build_mode" = x"local" ; then
+ build_mode=tidy
+fi
+
# $tidy: compile in a t2d directory.
# $clean: remove all the aux files.
case $build_mode in
@@ -1848,7 +1852,8 @@ do
# in compiling this document.
case $build_dir in
'' | . ) t2ddir=$out_noext.t2d ;;
- *) # Avoid collisions between multiple occurrences of the same
+ *) ensure_dir "$build_dir"
+ # Avoid collisions between multiple occurrences of the same
# file, so depend on the output path. Remove leading `./',
# at least to avoid creating a file starting with `.!', i.e.,
# an invisible file. The sed expression is fragile if the cwd
@@ -1860,7 +1865,7 @@ do
# Remove it at exit if clean mode.
trap "cleanup" 0 1 2 15
- ensure_dir "$build_dir" "$t2ddir"
+ ensure_dir "$t2ddir"
# Sometimes there are incompatibilities between auxiliary files for
# DVI and PDF. The contents can also change whether we work on PDF
> Remember also about the help message:
>
> "
> --build-dir=DIR specify where the tidy compilation is performed;
> implies --tidy;
> defaults to TEXI2DVI_BUILD_DIRECTORY
Re: [PATCH] Texinfo: inconsistent behavior: cmd line vs. env
Gavin Smith , Wed Mar 22 2023 20:06:49
GMT+0100 (Central European Standard Time)
On Tue, Mar 21, 2023 at 02:13:40PM +0100, Bogdan wrote:
Hello.
As suggested by Gavin, I'm reporting a problem (or at least a "surprising
inconsistency") in the texi2dvi script. This is related to Automake
bug#29188 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29188).
Since texinfo-4.9, one can set the build directory with an environment
variable "TEXI2DVI_BUILD_DIRECTORY". Unfortunately, texinfo has a
problem/inconsistency there. When setting "--build-dir=" on the command
line, the build mode is set to "tidy" (which cleans some log files, etc.).
Fine. The problem is that if you set the build directory using an
environment variable, the mode is NOT set to "tidy", leaving the logs files
(and failing tests in Automake). Luckily, you can also set the build mode
from an environment variable, "TEXI2DVI_BUILD_MODE".
I guess that TEXI2DVI_BUILD_DIRECTORY must be rarely used because this
hasn't been reported before.
I believe. Probably not many wish to have such a high level of
compatibility with both the new and old Texinfo, and so most people
simply use command-line switches. But it's so good that the
environment variable now exists!
The existing behaviour doesn't seem useful,
and I'm in favour of simplifying the possible configurations, so it
seems like a good idea to make setting TEXI2DVI_BUILD_DIRECTORY equivalent
to using --build-dir, as you suggest.
To summarize, if TEXI2DVI_BUILD_DIRECTORY was set, but --tidy (or --clean)
wasn't given, then the build directory would be created, but all the
auxiliary files would be dumped in the current directory.
Yes. As a side effect, this would cause test failures in Automake if
just the environment variable and only this particular environment
variable was set, because some tests check for left-over files in the
build directory.
There is still the minor question of what should happen if
TEXI2DVI_BUILD_DIRECTORY is set to '.' (the default). Since this is the
default value, it doesn't seem right that explicitly setting
TEXI2DVI_BUILD_DIRECTORY=. in the environment should change the
behaviour of texi2dvi.
I *was* thinking about this, too. On the other hand, if the user
gives "--build-dir=.", it *would* imply --tidy, even though this is
the default. The sole presence of the switch changes the behaviour.
I'm thinking also about situations like
export TEXI2DVI_BUILD_DIRECTORY=$some_runtime_var
and
texi2dvi --build-dir=$some_runtime_var ...
where 'some_runtime_var' can be any directory, or '.' as a fallback,
in some user script.
Even if it ends up in the '.' fallback, it still means the user
explicitly chose to use the command-line switch (which implies --tidy)
or the environment variable (which doesn't imply --tidy right now).
In other words, for consistency and no-surprises, it should be:
--build-dir given => --tidy
TEXI2DVI_BUILD_DIRECTORY given => --tidy
whatever the values.
I like the simplicity that the environment variable is used to set
the internal 'build_dir' variable exactly once, and is never used again.
Maybe it seems like I'm being picky here, but texi2dvi is at the borderline
of being difficult to make sense of, and any extra complications in terms
of possible configurations could push it over the edge.
I understand and I'm not claiming that my patch is perfect.
Hence, I propose the following patch:
diff --git a/util/texi2dvi b/util/texi2dvi
index 28c53ebe44..29b0abd453 100755
--- a/util/texi2dvi
+++ b/util/texi2dvi
@@ -1694,7 +1694,7 @@ while test x"$1" != x"$arg_sep"; do
-~ ) verbose "Option -~ is obsolete: texi2dvi ignores it.";;
-b | --batch) ;; # Obsolete
--build) shift; build_mode=$1;;
- --build-dir) shift; build_dir=$1; build_mode=tidy;;
+ --build-dir) shift; build_dir=$1;;
-c | --clean) build_mode=clean;;
-D | --debug) debug=true;;
-e | -E | --expand) expand=true;;
@@ -1743,6 +1743,10 @@ done
# Pop the token
shift
+if test x"$build_dir" != x"." && test x"$build_mode" = x"local" ; then
+ build_mode=tidy
+fi
+
# $tidy: compile in a t2d directory.
# $clean: remove all the aux files.
case $build_mode in
It still sets build_mode to tidy based on the build directory, but in only
one place in the code, not in two.
Certainly makes sense, and is probably the way it was meant to be
(in other words, clean some external directories). Shouldn't hurt
Automake's tests, I think.
Remember also about the help message:
"
--build-dir=DIR specify where the tidy compilation is performed;
implies --tidy;
defaults to TEXI2DVI_BUILD_DIRECTORY
[$build_dir]
"
For some reason, it was made so that passing --build-dir implies
--tidy... But, maybe just for the non-default values, as I wrote above
("external directories").
My patch may have the problem
