Bug#748271: [latex-cjk-common] latex command did not work until I ran it once under superuser!?
Hi Zephyrus
I think that trapping errors when disks get full is a bit tricky,
because that status in itself also needs to get written to a status
file. At least, that is how I expect apt/dpkg to work, but
"Ididnotreadthefinemanualnorthesourcecode".
Anyway, I'm happy that you are again a working TeXlive setup.
BR
--
Danai
On 19 May 2014 22:01, Zephyrus C <zephyrus8080@gmail.com> wrote:
> 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
>
>
Reply to: