Processed: Re: Bug#388399: FTBFS problems on alpha, mips[el]: Please help debugging
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
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
[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
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
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
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
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
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
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
[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
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
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
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
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
[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
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
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
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
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
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
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)
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)
