Bug#748271: [latex-cjk-common] latex command did not work until I ran it once under superuser!?

Hi,

Thank you for your comment.

2014-05-19 16:43 GMT+09:00 Danai SAE-HAN (韓達耐) <danai.sae-han@edpnet.be>:

Hi Zephyrus

I have been trying to unravel the exact problem you are facing, and it
seems that the problem has more to do with the way that Debian
packages got installed, and that some of the post-installation steps
did not go into error mode.

Yes, I agree. It looks that my piece-meal installation of TeX packages using aptitude (or apt-get) may have encountered a missing dependency or maybe uncovered a situation where
a failing command did not stop apt-get/aptitude as failure eventually.

However, this bug thread has become a bit convoluted. To clear up
things, I would like you to answer a number of questions.

Yes, I wil ltry.

1. Does pTeX run fine when you parse your minimal TeX document under
user "root"? (BTW, I am not advocating this as your normal process;
please run TeX binaries under a normal user account for regular use.)

It does. Oh, wait, that was now under an ordinary account.

Let me check now under superuser:

root@vm-debian-amd64:/tmp# ptex foo.tex
This is pTeX, Version 3.1415926-p3.4 (utf8.euc) (TeX Live 2013/Debian)
restricted \write18 enabled.
(./foo.tex [1] )
Output written on foo.dvi (1 page, 212 bytes).
Transcript written on foo.log.
root@vm-debian-amd64:/tmp#

So, it works under superuser.

2. As Norbert has suggested, please run "dpkg -l tex-common" under user "root".

I am quoting it here again, and it looks OK (that is a problem from the viewpoint of debugger. I wish it is not installed properly, but according to dpkg it is, and this is consistent of my observation that aptitude/apt-get succeeded as far as I could tell.)

dpkg -l tex-common
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==================-==============-==============-==========================================
ii tex-common 4.04 all common infrastructure for building and ins

3. Space issues and appropriate error traps can perhaps be
accommodated by the CJK packages, TeXlive packages or even the dpkg
packages. But I need to understand a bit more about your current
setup, and if packages were upgraded according to a process that is
not out of the ordinary.
Can you please summarise your installation / upgrade path?

I am using testing repository on top of the stable repository.
I am quoting my /etc/apt/sources.list here again. Other than that, there is nothing special.

---- /etc/apt/sources.list

#

# deb cdrom:[Debian GNU/Linux 7.1.0 _Wheezy_ - Official amd64 NETINST Binary-1 20130615-23:04]/ wheezy main

#deb cdrom:[Debian GNU/Linux 7.1.0 _Wheezy_ - Official amd64 NETINST Binary-1 20130615-23:04]/ wheezy main

deb http://ftp.jp.debian.org/debian/ wheezy main
deb http://ftp.jp.debian.org/debian/ testing main
deb-src http://ftp.jp.debian.org/debian/ wheezy main

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main

# wheezy-updates, previously known as 'volatile'
deb http://ftp.jp.debian.org/debian/ wheezy-updates main
deb-src http://ftp.jp.debian.org/debian/ wheezy-updates main

--- end of /etc/apt/sources.list

However, do note that I tend to

install smaller TeX packages first individually (and let aptitude / apt-get handle the dependency.

This is to save as much space as possible in my installed linux image.

(Although I tried to create large enough /usr and /var, I am afraid that after so many packages
and larger packages lately, I am running out of the space now.

That is why, I mentioned texlive-lang-cjk was split into C-part, J-part and K-part back in 2012 and so I could save space by not installing C-part and did not have to load the largish Chinese font.
Also, a doc package from TeXlive was a separate and independent package back in 2012 and thus I could remove it without aptitude/apt-get complaining. This saved another few hundred MB (!).

The system always reserves some space on the hard disk for user root.
When your disk is 99.9xx% full, processes run under regular users will
face problems, but user root still has a bit of space left. However,
"dpkg" is also run under user root, so my guess is that your disk was
temporarily 100% full, and that some errors may not have been trapped.

After reading Norbert's comments now, I think this could be it.

So the tough part was "some errors may not have been trapped".

I wish all such errors were trapped.

Any idea how I could check this locally as new packages come out?

TIA

Thank you.

Thank you again. My bug report boils down that

there seem to be one or few commands that fail to report back the error properly to invoking process when the execution failed due to low-space conditions. But nobody including the reporter is sure when such errors occured during installation. Oh well.

--
Danai