Processed: Re: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-10-05 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

> reassign 388399 tex-common
Bug#388399: "mktexmf: line 92: mf31966.tmp: Permission denied" on alpha, mips 
and mipsel
Bug reassigned from package `tetex-bin' to `tex-common'.

> severity 388399 normal
Bug#388399: "mktexmf: line 92: mf31966.tmp: Permission denied" on alpha, mips 
and mipsel
Severity set to `normal' from `serious'

> retitle  388399 document that packages need to clean up their font cache
Bug#388399: "mktexmf: line 92: mf31966.tmp: Permission denied" on alpha, mips 
and mipsel
Changed Bug title.

> stop
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-10-05 Thread Frank Küster
reassign 388399 tex-common
severity 388399 normal
retitle  388399 document that packages need to clean up their font cache
stop

Steve Langasek <[EMAIL PROTECTED]> wrote:

>> That's actually a good idea, yes.  Package maintainers have to set
>> TEXMFVAR so something inside the current directory.  Is the Makefile
>> variable $(CURDIR) safe for this?
>
> For identifying the current directory, yes.  TEXMFVAR should be a subdir, of
> course. :)

I've documented that in the TeX Policy draft, and am going to close this
bug when it is uploaded.  Not that everyone will read it...  Since
documenting what's already implicit in the Debian Policy, 4.9, "clean"
target, isn't release-critical, and the actual build failure should be
solved, I'm adjusting the severity.

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



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-10-04 Thread Steve Langasek
[Frank, you seem to have a wrong mail alias for me somewhere;
[EMAIL PROTECTED] is no longer in use, but that's where your cc: was
sent.]

On Wed, Oct 04, 2006 at 09:32:16AM +0200, Frank Küster wrote:
> > However, he also agrees with me that every package affected by this bug is
> > violating policy in its package builds: a package's clean target has to undo
> > everything done by the build and binary targets, which is not possible if
> > it's leaving cache files around on the system.

> I agree with you, and I'm also glad that you came up with a proposal for
> a good solution.  

> However, I'd like to point out that this problem is not special to TeX.
> Many programs create ~/.progname directories when run for the first time
> - and these directories contain configuration options which might cause
> trouble, since they are not updated or subject to dpkg conffile
> questions when the package changes configuration options.  It might be a
> good thing to require such tools to have a commandline switch or obey a
> commandline variable that prevents this.  Alternatively, HOME could be
> set to the temporary build directory, so that everything happens there.

Yes, that's true.  Setting $HOME to something explicitly nuked by the clean
target might be a good general solution.  In practice, there are few tools
that have broken buildd chroots in the manner that tex seems to have here.

> > the next best
> > option is for the tex maintainers to provide documentation to package
> > maintainers who build-depend on tex for using a local, in-tree font cache
> > that they can wipe out as part of their clean target, leaving the rest of
> > the system unaffected.

> That's actually a good idea, yes.  Package maintainers have to set
> TEXMFVAR so something inside the current directory.  Is the Makefile
> variable $(CURDIR) safe for this?

For identifying the current directory, yes.  TEXMFVAR should be a subdir, of
course. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-10-04 Thread Frank Küster
Hi Ryan,

Steve Langasek <[EMAIL PROTECTED]> wrote:

> On Sat, Sep 30, 2006 at 11:31:14AM +0200, Frank Küster wrote:
>> > But if the package build requires access to $HOME/.texmf-var, that's still 
>> > a
>> > bug that should be fixed; 
>
>> No it doesn't require that.  Only if there is a $HOME directory, and it
>> is writable, then it is used.  Otherwise /tmp/texfonts is used
>> instead. 
>
> I've chatted with Ryan Murray about this, who maintains the buildds for the
> three archs in question.  He's agreed to look into removing /home/buildd on
> these buildds when he has a chance.

Thank you.  You would have saved me a second of horror if you'd put here
what you've written at the end of your mail, namely that Ryan has
examined that directory: I was about to cry out "don't do that".  


> However, he also agrees with me that every package affected by this bug is
> violating policy in its package builds: a package's clean target has to undo
> everything done by the build and binary targets, which is not possible if
> it's leaving cache files around on the system.

I agree with you, and I'm also glad that you came up with a proposal for
a good solution.  

However, I'd like to point out that this problem is not special to TeX.
Many programs create ~/.progname directories when run for the first time
- and these directories contain configuration options which might cause
trouble, since they are not updated or subject to dpkg conffile
questions when the package changes configuration options.  It might be a
good thing to require such tools to have a commandline switch or obey a
commandline variable that prevents this.  Alternatively, HOME could be
set to the temporary build directory, so that everything happens there.

> Ryan suggests that not caching fonts at all would be a good solution to
> this.  Since AIUI it is a design constraint of tex to cache these fonts as
> intermediary output from one tool used as input for another, 

Yes, that's a design constraint, and won't change in the next couple of
years. 

> the next best
> option is for the tex maintainers to provide documentation to package
> maintainers who build-depend on tex for using a local, in-tree font cache
> that they can wipe out as part of their clean target, leaving the rest of
> the system unaffected.

That's actually a good idea, yes.  Package maintainers have to set
TEXMFVAR so something inside the current directory.  Is the Makefile
variable $(CURDIR) safe for this?

> Had this been in place for whatever packages are generating documentation in
> their binary target (instead of their build target), the autobuilders never
> would have ended up with root-owned directories under
> /home/buildd/.texmf-var (which Ryan confirms is the case).  

Yes, that must be the cause.  

Thanks for debugging, and in particular for the good suggestion,

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



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-10-04 Thread Steve Langasek
On Sat, Sep 30, 2006 at 11:31:14AM +0200, Frank Küster wrote:
> > But if the package build requires access to $HOME/.texmf-var, that's still a
> > bug that should be fixed; 

> No it doesn't require that.  Only if there is a $HOME directory, and it
> is writable, then it is used.  Otherwise /tmp/texfonts is used
> instead. 

I've chatted with Ryan Murray about this, who maintains the buildds for the
three archs in question.  He's agreed to look into removing /home/buildd on
these buildds when he has a chance.

However, he also agrees with me that every package affected by this bug is
violating policy in its package builds: a package's clean target has to undo
everything done by the build and binary targets, which is not possible if
it's leaving cache files around on the system.  (The fact that buildds don't
actually call the clean target after calling the binary target is secondary,
really; the point is that package builds shouldn't be writing to the user's
home directory in the first place and *requiring* any cleanup, though I
can't find any reference to this in the current version of policy.)

Ryan suggests that not caching fonts at all would be a good solution to
this.  Since AIUI it is a design constraint of tex to cache these fonts as
intermediary output from one tool used as input for another, the next best
option is for the tex maintainers to provide documentation to package
maintainers who build-depend on tex for using a local, in-tree font cache
that they can wipe out as part of their clean target, leaving the rest of
the system unaffected.

Had this been in place for whatever packages are generating documentation in
their binary target (instead of their build target), the autobuilders never
would have ended up with root-owned directories under
/home/buildd/.texmf-var (which Ryan confirms is the case).  Had it been in
place for the packages that are currently failing to build, they wouldn't be
failing to build.  This makes it the preferable, most robust solution, not
depending on other packages to behave themselves wrt any caches that might
exist on the system.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-30 Thread Steve Langasek
On Sat, Sep 30, 2006 at 11:56:30PM +0100, Thiemo Seufer wrote:
> > > I meant the the earlier security bug you mentioned. To me, the solution
> > > for the earlier bug as well as the current one looks like keeping the
> > > font cache in /var but maintaining it via a mktexmf user.

> > The problem is that mktexmf is a shell script (=no suid possible) that
> > is started with the rights of the user. So the former solution required
> > all users that wanted to use TeX to have write access below
> > /var/cache/fonts.

> Then I fail to understand

>   a) why the old solution was a security problem when it does something
>  similiar to e.g. /var/mail, and leaves the root-reserved part of
>  the filesystem free,

>   b) why moving the cache to $HOME or /tmp fixed the problem, given
>  that all three probably reside on the same partition.

The old solution was a security problem because the directories were
world-writable -- /var/mail is not, the directory is only writable by the
'mail' group -- which almost certainly makes symlink attacks possible,
looking at the source of mktexmf, as well as cache poisoning attacks.

The new solution is only better if the cache is written in the home
directory; if it's written to /tmp/texfonts for any reason, the security is
just as bad.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-30 Thread Steve Langasek
On Sat, Sep 30, 2006 at 08:19:22PM +0200, Ralf Stubner wrote:
> On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote:
> > Frank Küster wrote:
> > > Thiemo Seufer <[EMAIL PROTECTED]> wrote:

> > > > So, if I understand that correctly, the bug was fixed by running mktexmf
> > > > as non-root, and the change of the cache location is only a collateral.

> > > No, or I do not understand what you mean.

> > I meant the the earlier security bug you mentioned. To me, the solution
> > for the earlier bug as well as the current one looks like keeping the
> > font cache in /var but maintaining it via a mktexmf user.

> The problem is that mktexmf is a shell script (=no suid possible)

Where does the input for the cache come from?  If the input is always from a
privileged location (i.e., /usr/share, /usr/lib, /etc), then it's possible
-- and, I think, vastly preferable -- to have an suid wrapper for mktexmf to
manage /var/cache.

If the font input comes from user-specified, non-privileged locations, then
this can't ever be safely written to a shared location.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-30 Thread Thiemo Seufer
Ralf Stubner wrote:
> On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote:
> > Frank Küster wrote:
> > > Thiemo Seufer <[EMAIL PROTECTED]> wrote:
> > > >
> > > > So, if I understand that correctly, the bug was fixed by running mktexmf
> > > > as non-root, and the change of the cache location is only a collateral.
> > > 
> > > No, or I do not understand what you mean.
> > 
> > I meant the the earlier security bug you mentioned. To me, the solution
> > for the earlier bug as well as the current one looks like keeping the
> > font cache in /var but maintaining it via a mktexmf user.
> 
> The problem is that mktexmf is a shell script (=no suid possible) that
> is started with the rights of the user. So the former solution required
> all users that wanted to use TeX to have write access below
> /var/cache/fonts.

Then I fail to understand

  a) why the old solution was a security problem when it does something
 similiar to e.g. /var/mail, and leaves the root-reserved part of
 the filesystem free,

  b) why moving the cache to $HOME or /tmp fixed the problem, given
 that all three probably reside on the same partition.


Thiemo



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-30 Thread Ralf Stubner
On Sat, Sep 30, 2006 at 18:12 +0100, Thiemo Seufer wrote:
> Frank Küster wrote:
> > Thiemo Seufer <[EMAIL PROTECTED]> wrote:
> > >
> > > So, if I understand that correctly, the bug was fixed by running mktexmf
> > > as non-root, and the change of the cache location is only a collateral.
> > 
> > No, or I do not understand what you mean.
> 
> I meant the the earlier security bug you mentioned. To me, the solution
> for the earlier bug as well as the current one looks like keeping the
> font cache in /var but maintaining it via a mktexmf user.

The problem is that mktexmf is a shell script (=no suid possible) that
is started with the rights of the user. So the former solution required
all users that wanted to use TeX to have write access below
/var/cache/fonts. In addition for buildds the default now-questions-
asked installation had to have directories below /var/cache/fonts with
world write access. We had a system to restrict these rights to some
group, but the debconf question and code were quite complicated and
confused many users.

cheerio
ralf



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-30 Thread Frank Küster
[Summary for the buildd people: We still need your input]

Thiemo Seufer <[EMAIL PROTECTED]> wrote:

>> >  sudo mkdir -p /tmp/texfonts/source/jknappen/ec
>> >  sudo mkdir -p /tmp/texfonts/tfm/jknappen/ec
>> >  make -C docs/psdoc
>> >
>> > So somewhere, there is a very, very wrong assumption that it's ok to use a
>> > fixed, user-invariant path under /tmp for writing out fonts.
>> 
>> I do not think that this is a bug, and anyway it's unrelated to the
>> FTBFS problem.  Previously fonts were created below /var, but this was
>> regarded as a security risk because users would be able to completely
>> fill up /var.  Now the font cache is in the users' directories, and only
>> as a fallback it is in /tmp/texfonts.
>
> So, if I understand that correctly, the bug was fixed by running mktexmf
> as non-root, and the change of the cache location is only a collateral.

No, or I do not understand what you mean.  The bug we are sending this
to, #388399, is still open and RC, and nothing was fixed.  I was just
describing the history of the font cache, in order to have an argument
why a user-invariant font cache directory might be acceptable.  But
that's a different issue, not related to #388399, and I have already
sent a mail to [EMAIL PROTECTED] to separate this out.

The bug #388399 still persists, and so far it only manifests itself on
three buildds for alpha, mips and mipsel, and no one else has been able
to reproduce it.  And I must say that it really sucks to exchange so
many e-mails on the topic without any input from the people who actually
could help.

>> If the admin chooses to create an empty /tmp/texfonts hierarchy without
>> write access for users that need the font cache, that's equivalent to
>> him creating an empty /var/cache/fonts/... without users having write
>> access, in the old setup.  You're allowed to shoot yourself into the
>> foot. 
>
> AFAIU any user on the system could create /tmp/texfonts and break
> mktexmf that way.

You are right, and while that's not a problem in most cases (hardly any
system except buildds and build chroots have users without writable home
directories that use TeX, and obviously up to now no system had two of
them), it is a bug.

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



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-30 Thread Thiemo Seufer
Frank Küster wrote:
> [Summary for the buildd people: We still need your input]
> 
> Thiemo Seufer <[EMAIL PROTECTED]> wrote:
> 
> >> >  sudo mkdir -p /tmp/texfonts/source/jknappen/ec
> >> >  sudo mkdir -p /tmp/texfonts/tfm/jknappen/ec
> >> >  make -C docs/psdoc
> >> >
> >> > So somewhere, there is a very, very wrong assumption that it's ok to use 
> >> > a
> >> > fixed, user-invariant path under /tmp for writing out fonts.
> >> 
> >> I do not think that this is a bug, and anyway it's unrelated to the
> >> FTBFS problem.  Previously fonts were created below /var, but this was
> >> regarded as a security risk because users would be able to completely
> >> fill up /var.  Now the font cache is in the users' directories, and only
> >> as a fallback it is in /tmp/texfonts.
> >
> > So, if I understand that correctly, the bug was fixed by running mktexmf
> > as non-root, and the change of the cache location is only a collateral.
> 
> No, or I do not understand what you mean.

I meant the the earlier security bug you mentioned. To me, the solution
for the earlier bug as well as the current one looks like keeping the
font cache in /var but maintaining it via a mktexmf user.


Thiemo



Processed: Re: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-30 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

> clone 388399 -1
Bug#388399: "mktexmf: line 92: mf31966.tmp: Permission denied" on alpha, mips 
and mipsel
Bug 388399 cloned as bug 390349.

> retitle -1 Font cache, when in /tmp, should use per-user directories
Bug#390349: "mktexmf: line 92: mf31966.tmp: Permission denied" on alpha, mips 
and mipsel
Changed Bug title.

> severity -1 important
Bug#390349: Font cache, when in /tmp, should use per-user directories
Severity set to `important' from `serious'

> submitter -1 Steve Langasek <[EMAIL PROTECTED]>
Bug#390349: Font cache, when in /tmp, should use per-user directories
Changed Bug submitter from "Alex Owen" <[EMAIL PROTECTED]> to Steve Langasek 
<[EMAIL PROTECTED]>.

> stop
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-30 Thread Frank Küster
clone 388399 -1
retitle -1 Font cache, when in /tmp, should use per-user directories
severity -1 important
submitter -1 Steve Langasek <[EMAIL PROTECTED]>
stop

Frank Küster <[EMAIL PROTECTED]> wrote:

> Steve Langasek <[EMAIL PROTECTED]> wrote:
>
>> So somewhere, there is a very, very wrong assumption that it's ok to use a
>> fixed, user-invariant path under /tmp for writing out fonts.
>
> [...] Why should it be more wrong to use a user-invariant path in
> /tmp than a user-invariant path in /var?  Note that we cannot use
> directories created with mktemp or so, because it's not possible to pass
> on the directory name from the process that creates the dir, to the one
> that creates the font and to the one that uses it.

But you are right, Steve, that it might cause problems.  I make this a
separate bug, and I'm already investigating a solution.

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



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-30 Thread Thiemo Seufer
Frank Küster wrote:
> [Summary for the buildd people: We still need your help]
> 
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> 
> > But if the package build requires access to $HOME/.texmf-var, that's still a
> > bug that should be fixed; 
> 
> No it doesn't require that.  Only if there is a $HOME directory, and it
> is writable, then it is used.  Otherwise /tmp/texfonts is used
> instead. 
> 
> > Anyway, here's how I *am* able to reproduce the bug:
> 
> No, that's not the same bug.
> 
> >  sudo mkdir -p /tmp/texfonts/source/jknappen/ec
> >  sudo mkdir -p /tmp/texfonts/tfm/jknappen/ec
> >  make -C docs/psdoc
> >
> > So somewhere, there is a very, very wrong assumption that it's ok to use a
> > fixed, user-invariant path under /tmp for writing out fonts.
> 
> I do not think that this is a bug, and anyway it's unrelated to the
> FTBFS problem.  Previously fonts were created below /var, but this was
> regarded as a security risk because users would be able to completely
> fill up /var.  Now the font cache is in the users' directories, and only
> as a fallback it is in /tmp/texfonts.

So, if I understand that correctly, the bug was fixed by running mktexmf
as non-root, and the change of the cache location is only a collateral.

> This was particularly designed
> for machines like buildds, where $HOME might be nonexistent or
> unwritable.  I think it was even discussed on -devel, but maybe not the
> details.  Why should it be more wrong to use a user-invariant path in
> /tmp than a user-invariant path in /var?

Because /var isn't a free-for-all scratch space like /tmp.

> Note that we cannot use
> directories created with mktemp or so, because it's not possible to pass
> on the directory name from the process that creates the dir, to the one
> that creates the font and to the one that uses it.
> 
> If the admin chooses to create an empty /tmp/texfonts hierarchy without
> write access for users that need the font cache, that's equivalent to
> him creating an empty /var/cache/fonts/... without users having write
> access, in the old setup.  You're allowed to shoot yourself into the
> foot. 

AFAIU any user on the system could create /tmp/texfonts and break
mktexmf that way.


Thiemo



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-30 Thread Frank Küster
[Summary for the buildd people: We still need your help]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> But if the package build requires access to $HOME/.texmf-var, that's still a
> bug that should be fixed; 

No it doesn't require that.  Only if there is a $HOME directory, and it
is writable, then it is used.  Otherwise /tmp/texfonts is used
instead. 

> Anyway, here's how I *am* able to reproduce the bug:

No, that's not the same bug.

>  sudo mkdir -p /tmp/texfonts/source/jknappen/ec
>  sudo mkdir -p /tmp/texfonts/tfm/jknappen/ec
>  make -C docs/psdoc
>
> So somewhere, there is a very, very wrong assumption that it's ok to use a
> fixed, user-invariant path under /tmp for writing out fonts.

I do not think that this is a bug, and anyway it's unrelated to the
FTBFS problem.  Previously fonts were created below /var, but this was
regarded as a security risk because users would be able to completely
fill up /var.  Now the font cache is in the users' directories, and only
as a fallback it is in /tmp/texfonts.  This was particularly designed
for machines like buildds, where $HOME might be nonexistent or
unwritable.  I think it was even discussed on -devel, but maybe not the
details.  Why should it be more wrong to use a user-invariant path in
/tmp than a user-invariant path in /var?  Note that we cannot use
directories created with mktemp or so, because it's not possible to pass
on the directory name from the process that creates the dir, to the one
that creates the font and to the one that uses it.

If the admin chooses to create an empty /tmp/texfonts hierarchy without
write access for users that need the font cache, that's equivalent to
him creating an empty /var/cache/fonts/... without users having write
access, in the old setup.  You're allowed to shoot yourself into the
foot. 

> Removing /tmp/texfonts and creating ~/.texmf-var/fonts instead as root
> doesn't give the same failure.

And that's the point:  In the build logs, the output dir is below
~/.texmf-var/fonts, but it seems to be unwritable.  And this just looks
like a bug in the setup on the buildds - or instead a subtle bug in our
configuration files or scripts.  At least it's something nobody so far
was able to reproduce.

Regards, Frank

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



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-29 Thread Steve Langasek
On Fri, Sep 29, 2006 at 01:35:14PM +0200, Frank Küster wrote:

> > On Fri, Sep 29, 2006 at 10:54:36AM +0200, Frank Küster wrote:

> >> I'm resending this mail, and include the porters list with hope for some
> >> help.  We really won't be able to debug this problem without contact to
> >> someone who has at least read access to the affected buildds.

> > You can debug it by using -rsudo for your package builds instead of
> > -rfakeroot.

> Sorry, I don't understand.  Do you mean that you are able to reproduce
> the problem, somehow using sudo?  In what environment?  A pbuilder where
> you become a non-priviledged user without giving him a home directory?
> Or does the home directory existence not matter with sudo?

Well, I had assumed that the breakage was caused directly by this package's
own mishandling of the root command, but that doesn't seem to be the case.

But if the package build requires access to $HOME/.texmf-var, that's still a
bug that should be fixed; package builds aren't allowed to change anything
in the build environment outside of the build dir (and parent dir, for
writing out generated packages).

Anyway, here's how I *am* able to reproduce the bug:

 sudo mkdir -p /tmp/texfonts/source/jknappen/ec
 sudo mkdir -p /tmp/texfonts/tfm/jknappen/ec
 make -C docs/psdoc

So somewhere, there is a very, very wrong assumption that it's ok to use a
fixed, user-invariant path under /tmp for writing out fonts.

Removing /tmp/texfonts and creating ~/.texmf-var/fonts instead as root
doesn't give the same failure.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-29 Thread Frank Küster
Hi,

despite all tips, this is still a plea to the people with access to the
buildds. 

Thiemo Seufer <[EMAIL PROTECTED]> wrote:

> It looks like the build creates font files with root permissions, and
> can't alter them lateron when running without elevated privileges.
> So any environment with real root permissions should show the problem.

No, it does not, I still need the help of someone with access to the
buildds.  I know it does not show the problem, both because I tried and
because I analysed why it cannot.

1. I tried:

$ rm -rf ~/.texmf-var/fonts
$ apt-get source gnuplot
$ cd gnuplot-4.0.0
$ dpkg-buildpackage -d -b -uc -rsudo
dpkg-buildpackage: source package is gnuplot
dpkg-buildpackage: source version is 4.0.0-5
dpkg-buildpackage: source maintainer is Cyril Bouthors <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture is i386
 sudo debian/rules clean
Password:
[...]

works without problems, and creates font cache files in
~/.texmf-var/fonts that are *not* owned by root:

$ find .texmf-var/ -user 0
$ find .texmf-var/ -user frank | wc -l
78
$ find .texmf-var/  | wc -l
78
$ 

2. I analysed: 

$ export KPATHSEA_DEBUG=512
$ dpkg-buildpackage -d -b -uc -rsudo 2>&1 | tee ../sudo.lg

shows that the call that fails in the build log at
http://buildd.debian.org/fetch.php?&pkg=gnuplot&ver=4.0.0-5&arch=alpha&stamp=1158062374&file=log&as=raw
is the first call to mktextfm.  This is a shell script which first
creates the output directory, then changes to it, and writes its output
into a temporary file, mf31966.tmp in this case.  This is where the
script fails.  

The only explanation I currently have is that on the problematic
buildds, the directory exists, but is owned and writable only by root.
The reason for this may actually be a bug in a TeX package, or just a
misconfiguration.  But we won't find out without looking at the systems
affected. 

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



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-29 Thread Thiemo Seufer
Frank Küster wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> 
> > On Fri, Sep 29, 2006 at 10:54:36AM +0200, Frank Küster wrote:
> >
> >> I'm resending this mail, and include the porters list with hope for some
> >> help.  We really won't be able to debug this problem without contact to
> >> someone who has at least read access to the affected buildds.
> >
> > You can debug it by using -rsudo for your package builds instead of
> > -rfakeroot.
> 
> Sorry, I don't understand.  Do you mean that you are able to reproduce
> the problem, somehow using sudo?  In what environment?  A pbuilder where
> you become a non-priviledged user without giving him a home directory?
> Or does the home directory existence not matter with sudo?

It looks like the build creates font files with root permissions, and
can't alter them lateron when running without elevated privileges.
So any environment with real root permissions should show the problem.


Thiemo



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-29 Thread Frank Küster
Steve Langasek <[EMAIL PROTECTED]> wrote:

> On Fri, Sep 29, 2006 at 10:54:36AM +0200, Frank Küster wrote:
>
>> I'm resending this mail, and include the porters list with hope for some
>> help.  We really won't be able to debug this problem without contact to
>> someone who has at least read access to the affected buildds.
>
> You can debug it by using -rsudo for your package builds instead of
> -rfakeroot.

Sorry, I don't understand.  Do you mean that you are able to reproduce
the problem, somehow using sudo?  In what environment?  A pbuilder where
you become a non-priviledged user without giving him a home directory?
Or does the home directory existence not matter with sudo?

TIA, Frank

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



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-29 Thread Steve Langasek
On Fri, Sep 29, 2006 at 10:54:36AM +0200, Frank Küster wrote:

> I'm resending this mail, and include the porters list with hope for some
> help.  We really won't be able to debug this problem without contact to
> someone who has at least read access to the affected buildds.

You can debug it by using -rsudo for your package builds instead of
-rfakeroot.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging

2006-09-27 Thread Frank Küster
Frank Küster <[EMAIL PROTECTED]> wrote:

> Dear Buildd admins, 
>
> there seems to be a problem with packages that build-depend on tetex,
> which only manifests on the alpha, mips and mipsel buildds.  We need
> your help to investigate this, please see below.

Nobody has answered quickly, but I found that we have accumulated a lot
of changes in tetex-bin, more than I remembered, since the last upload.
I am therefore going to upload the current version as-is.  Anyway, I'd
be surprised if there's a bug in tetex-bin, I rather think it's a bug in
tex-common or, more likely, a misconfiguration of the buildds.

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



Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging (was: Bug#388399: Processed: Re: Bug#388399: gnuplot: FTBFS)

2006-09-26 Thread Frank Küster
Dear Buildd admins, 

there seems to be a problem with packages that build-depend on tetex,
which only manifests on the alpha, mips and mipsel buildds.  We need
your help to investigate this, please see below.

Ralf Stubner <[EMAIL PROTECTED]> wrote:

> The strange thing is that mktexmf, which is called here, looks like this:
>
> [...]
> destdir=`echo "$MT_MFNAME" | sed 's%/[^/][^/]*$%%'`
> test -d "$destdir" || "$MT_MKTEXDIR" "$destdir" || exit 1
> cd "$destdir" || exit 1
> [...]
> cat > "mf$$.tmp" < [...]
> chmod `kpsestat -xst,go-w .` "mf$$.tmp"  ### second
> rm -f "$mfname"
> mv "mf$$.tmp" "$mfname"  ### third 
>
> echo "$destdir/$mfname" >$STDOUT
> echo "$progname: $destdir/$mfname: successfully generated." >&2
> "$MT_MKTEXUPD" "$destdir" "$mfname"
> [...]
>
>>From the succesfull messages at the end of mktexmf we know that $destdir
> was /home/buildd/.texmf-var/fonts/source/jknappen/ec/, which must have
> existed otherwise the script would have been terminated before. So at
> first sight it looks as if $destdir was created but without write
> permissions. No idea why that could happen.

Buildd admins, could you please check this?  Does any of these
directories exist, and would the user under whose name the build is done
have write access there?

The TeX packages usually create their fonts in a hierarchy below the
user's home directory.  Especially for buildds, we have arranged that
when the home directory does not exist or is not writable, fonts are
cached in /tmp/texfonts.  Could it be that on the affected systems,
the directories in /home/buildd already exist, but are not writable?

Alternatively, it would also make sense to copy /usr/bin/mktexmf to
/usr/local/bin on the buildd and add a "set -x" at the beginning, and
trigger a new build of gnuplot.

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