[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: latex-cjk upload to unstable ...



(Note that I'm changing to the new list)

Danai SAE-HAN (韓達耐) <danai.sae-han@skynet.be> wrote:

> Hmmm, I didn't think about that: the user can't sniff the logs if
> pbuilder fails.  Bummer.
>
> There are two reasons why I first redirected the output into log files
> instead of on-screen.  First was that there is so much information
> that it makes it difficult to follow what's happening exactly.
> Secondly and more importantly, when the scripts are bursting out so
> much information, it would slow (my) computer even more because my
> terminal couldn't follow, temporarily hijacking my CPU.

Yes, I agree.  I think we should not display the log when the build is
successful. 

> So there are two easy solutions:
> (1) either I won't redirect it anymore, or I will redirect it to the
>     screen as well (it's not that many people will build the package
>     themselves, I suspect).   This option carries my favour;
> (2) or I could redirect the output to a file in /tmp.  If I would
>     choose this last way, do I need to name the logs with $RANDOM in
>     the filename (Debian policy doesn't say anything about it, but I
>     have noticed that quite a few packages do this)?  Or can I call it
>     anything I like?  And would you suggest to delete the logfile
>     after the last successful command?
>
> A less elegant way would be to put an if clause around every command.

Hm.  I really don't understand why the Makefile snippet that I posted
wouldn't work.  Can you upload somewhere your current state of work?
Then I would try to find a way to do the redirection as I think it
should be done.

As for the file in /tmp, I don't think that makes sense.  This is a log
file with no sensitive content, and you do not analyse its content.  I
see no reason not to just call it ./log, or maybe more descriptive
./font-generation.log.  When we use tempfiles in maintainer scripts,
then it is because we grep for some error or success messages in them,
and let the script act accordingly.  In this case a predictable filename
must be avoided, because somebody else could interfere, e.g. with a
symlink attack, and cause the installation to fail although the output
contained the success message, or the other way round.  The impact of
such an attack on a TeX package is not large, but it's a general
security risk and therefore generally something to be avoided.

But not for output that is just displayed for the information of the
human package builder in case the build fails.

> .PP
> This manual page was written by Danai SAE-HAN <danai.sae-han@skynet.be>
> for the Debian project.  It is licensed under the GNU General Public
> License version 2 or higher, of which you can find a copy online at
> http://www.gnu.org/licenses/gpl.txt or on Debian systems under
> /usr/share/common-licenses/GPL-2 (part of the "base-files" package).

Fine.

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)



Reply to: