user release.debian@packages.debian.org
usertag 607857 squeeze-can-defer
tag 607857 squeeze-ignore
kthxbye
On Thu, Dec 23, 2010 at 10:54:10 +0900, Hideki Yamane wrote:
> package: texlive-base
> version: 2009-11
> severity: serious
>
> Hi,
>
> I've found that texlive-base package creates fi
On So, 26 Dez 2010, Norbert Preining wrote:
> So that means we only have to adapt the trigger action of tex-common.
> What do you say about that one:
Tested that code:
...cowbuilder
...
Setting up texlive-base (2009-11) ...
Running mktexlsr. This may take some time... done.
Building format(s) --al
HI Hilmar!
On Sa, 25 Dez 2010, Hilmar Preusse wrote:
> I hade a short look: texhash is only called one time shortly before
> the end of the mkMaps function, which is only called one time at the
> end of the main function. This means the updmap script itself does
> not need an ls-R db update during
On 25.12.10 Norbert Preining (prein...@logic.at) wrote:
Hi,
> By default, the TeX filename database is also rebuilt (with mktexlsr).
> ...
> --nohash do not run texhash
> ...
>
> So ... what is the solution? The simple idea would be to
> call updmap-sys --nohash, b
On 25.12.10 Hilmar Preusse (hill...@web.de) wrote:
> On 25.12.10 Norbert Preining (prein...@logic.at) wrote:
Hi,
> > It is not there, it is in tex-common: I adapted the postinst with
> > loads of debug and what did I found:
> >
> Well, I expected somthing like that.
>
> > So ... wha
On 25.12.10 Norbert Preining (prein...@logic.at) wrote:
> On Fr, 24 Dez 2010, Hilmar Preusse wrote:
Hi,
> > we have to go through texlive-base.postinst step by step and
> > check,
>
> It is not there, it is in tex-common: I adapted the postinst with
> loads of debug and what did I found:
>
Well
On Fr, 24 Dez 2010, Hilmar Preusse wrote:
> we have to go through texlive-base.postinst step by step and check,
It is not there, it is in tex-common: I adapted the postinst with
loads of debug and what did I found:
DEBUG 122:
DEBUG 123:
Running updmap-sys. This may take some time... DEBUG 124:
reassign 607857 texlive-base
retitle 607857 postinst script of texlive-base creates
/usr/local/share/texmf/ls-R
stop
On 24.12.10 Norbert Preining (prein...@logic.at) wrote:
Hi,
> The question is *WHY* an ls-R file is created there, because none
> of *our* scripts (AFAIS) creates it, all call mk
severity 607857 normal
thanks
On Fr, 24 Dez 2010, Hideki Yamane wrote:
> When mktexlsr is called, it creates ls-R file (yes, you know).
> And arguments contain /u/l/s, so every package calling mktexlsr
> makes ls-R file under /u/l/s as log (*)
Yes, then it is a bug in *these* packages, but not
On 24.12.10 Hideki Yamane (henr...@debian.or.jp) wrote:
Hi,
> >The question is *WHY* an ls-R file is created there, because none
> >of *our* scripts (AFAIS) creates it, all call mktexlsr with
> >a list of arguments, so do every package using dh_installtex and
> >triggers.
>
> When mktexlsr is c
tags 607857 - patch
thanks
Hi,
>The question is *WHY* an ls-R file is created there, because none
>of *our* scripts (AFAIS) creates it, all call mktexlsr with
>a list of arguments, so do every package using dh_installtex and
>triggers.
When mktexlsr is called, it creates ls-R file (yes, you kno
Hi Hideki,
what are you trying to do? Why do you not try to understand what I wrote
several times?
Yes, we know that we create /u/l/s/texmf, this is allowed by policy.
The question is *WHY* an ls-R file is created there, because none
of *our* scripts (AFAIS) creates it, all call mktexlsr with
a
reassign 607857 tex-common
tags 607857 patch
thanks
Hi,
I've tried it with pbuilder chroot environment, installed tex-common.
>r...@hp115:/# ls -l /usr/local/share/
>total 0
>drwxrwsr-x 2 root staff 40 Dec 21 08:40 man
>drwxrwsr-x 2 root staff 40 Dec 24 01:26 texmf
Oops, there's texmf!
>r..
On 23.12.10 Hideki Yamane (henr...@debian.or.jp) wrote:
Hi,
> Attach piuparts logs here, could you check it please?
>
Just a short notice: please compress logs before sending. This mail
didn't make it to the maintainer mailing list due to its size.
H.
--
sigmentation fault
--
To UNSUBSCR
On Fr, 24 Dez 2010, Hideki Yamane wrote:
> > does not exists, no ls-R file will be created there.
>
> It seems not.
It is *very* strange.
> Attach piuparts logs here, could you check it please?
THis convolute of unreadable bunch? I tried quite some time
to get something useful out of it, wit
On Do, 23 Dez 2010, Hideki Yamane wrote:
> I've confirmed same issue with texlive-xetex, but it is caused by another
> package... texlive-binaries.
Yes, we know *which* program is generating the ls-R files, thanks.
> > Processing triggers for tex-common ...
> > Running mktexlsr. This may ta
reassign 607857 texlive-binaries
thanks
Hi,
On Thu, 23 Dec 2010 13:19:00 +0100
Hilmar Preusse wrote:
> Well, that directory wasn't created by texlive-base, but by
> tex-common (which was installed as dep). In theory that dir should be
> gone after purging of tex-common. Could you check if this i
On 23.12.10 Hideki Yamane (henr...@debian.or.jp) wrote:
Hi,
> I've found that texlive-base package creates files in /usr/local.
> (thanks to piuparts)
>
> > 0m23.9s DEBUG: No broken symlinks as far as we can find.
> > 0m25.2s ERROR: FAIL: Package purging left files on system:
> > /usr/local/
package: texlive-base
version: 2009-11
severity: serious
Hi,
I've found that texlive-base package creates files in /usr/local.
(thanks to piuparts)
> 0m23.9s DEBUG: No broken symlinks as far as we can find.
> 0m25.2s ERROR: FAIL: Package purging left files on system:
> /usr/local/share/texmf
19 matches
Mail list logo
