Re: buildd administration -- TeX related FTBFS
Osamu Aoki [EMAIL PROTECTED] wrote: Hi, Osamu Aoki [EMAIL PROTECTED] wrote: ... I think one to ease tension is to make tetex packages to coexist in archive just like many gcc. [...] I should have been clear. I wish them to coexist only in archive but they can conflict each other to make only one of them to be installed. Maybe, dummy package to go with them is also nice. I know it is too much work to make them installable simultaneously. Maintaining 2 version are still a lot of work, though. That is in fact a good suggestion. It's too late now for teTeX-3.0; but for the next upstream release, or a possible switch to texlive, we'll definitely keep the other version around. As for auto-building some sections of archive in sid environment but overriding some packages with ones from experiment or local archive, I think pbuilder should be useful. (I will try it some time soonish. It should be quite simple.) pbuilder is nice, I use it all the time. But it's not very useful if you want to autobuild more than a couple of packages; setting up a real buildd is the method of choice here, but it isn't as trivial as pbuilder, it takes more machine power, bandwidth, and of course in the end you need to process all those packages... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: buildd administration -- TeX related FTBFS
Hi, On Tue, Dec 20, 2005 at 01:48:12PM +0100, Frank Küster wrote: Osamu Aoki [EMAIL PROTECTED] wrote: ... I think one to ease tension is to make tetex packages to coexist in archive just like many gcc. That would be nice - but it would cause even more work, I fear. And it would be the cause of even more bugs, because you can't just simply use one symlink pointing to the right place, but need to maintain a complete tree of TeX input and configuration files, in a setup where users can mix up trees with one changed line in the central configfile... I should have been clear. I wish them to coexist only in archive but they can conflict each other to make only one of them to be installed. Maybe, dummy package to go with them is also nice. I know it is too much work to make them installable simultaneously. Maintaining 2 version are still a lot of work, though. As for auto-building some sections of archive in sid environment but overriding some packages with ones from experiment or local archive, I think pbuilder should be useful. (I will try it some time soonish. It should be quite simple.) Osamu
Re: buildd administration -- TeX related FTBFS
Osamu Aoki [EMAIL PROTECTED] wrote: Hi, I realize TeX is tough program to maintain. Thanks to Frank. One quick and easy way to avoid TeX related build issues are to avoid using TeX related tools during build time. So the results will be Debian only ships documentations in plain text and HTML. (No PS and no PDF). But is it what we should do? Personally, I mostly work with the html versions if available (and with txt for grepping) and when I am sitting at the screen, but for important pieces of software I frequently print out a pdf or ps version, to be able to scribble some notes and stick post-its on it and read when the PC is switched off. Therefore I think we should have both. Anyway, the main problem is not so much that teTeX doesn't have enough maintainer power, but rather that many packages that generate (La)TeX code for documentation purposes are either basically unmaintained, or maintained only by users that don't know about the underlying TeX problems; and it seems to me that some of this also true for the respective upstreams. What makes a teTeX update hard is that it becomes the teTeX maintainer's task to find all the bugs in other packages, write patches, and often NMU and contact upstream. For example, when I got FTBFS RC bug due to tetex, I reassigned it to tetex. I should have reduced severity but I did not do it partly because of my wish to get Frank's attention and his assistance to fix it from Tetex package. Sorry. This may be the reason Frank felt about FTBFS/RC. It is not FTBFS for him and that was not RC for him. Yes, but for the issue that is in question here (How long is it acceptable to have a package in unstable with a dummy bug to prevent testing migration) it just doesn't matter whether it's my bug or yours. And of course I can't blame it on you that a package that you use for building your docs doesn't work together with teTeX-3.0, and has a maintainer who cannot solve the problem on their own; and I cannot blame them, either. I wish that tetex upgrade happens more like gcc upgrades. So testing both versions are much easier and, if needed, we can specify older version ones. [...] I think one to ease tension is to make tetex packages to coexist in archive just like many gcc. That would be nice - but it would cause even more work, I fear. And it would be the cause of even more bugs, because you can't just simply use one symlink pointing to the right place, but need to maintain a complete tree of TeX input and configuration files, in a setup where users can mix up trees with one changed line in the central configfile... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: buildd administration -- TeX related FTBFS
Osamu Aoki [EMAIL PROTECTED] wrote: I hope situation will be better soon but I am still struggling why debiandoc-sgml-doc fails to build nicely. (Yes, I know I can get by by not checking exit code during build process. But that is not a good fix I want to do.) Any help is appreciated. The last mail to the bug is from me, and I have not received an answer yet. Feel free to ask - just Cc debian-tetex-maint. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: buildd administration -- TeX related FTBFS
Hi, I realize TeX is tough program to maintain. Thanks to Frank. One quick and easy way to avoid TeX related build issues are to avoid using TeX related tools during build time. So the results will be Debian only ships documentations in plain text and HTML. (No PS and no PDF). But is it what we should do? On Sat, Dec 17, 2005 at 01:38:25PM +1000, Anthony Towns wrote: On Fri, Dec 16, 2005 at 11:24:39AM +0100, Frank Küster wrote: ... It's been in experimental for more than half a year. Err, that's kind of absurdly long too. But I din not use it then :-( ... Six months is a lot of time; and experimental should provide you with the space and machine power to handle the rebuilding. Yes and no. Rebuilding Debian Reference takes few hours on 2GHz machine. So it is not easy but possible with 6 months. But tracking down cause of failure is not that simple. tetex-base has over 70MB as installed (bigger than kernel source.) So it is quite time consuming and close to impossible for non-tex expert. I don't know how many source changes are necessary to do the rebuilding, though. The changes may be few strings but ... where? So either we could have delayed teTeX 3.0 until god-knows-when, Uh, no. The whole point is to delay _less_, not more. Yes. Many document build scripts implement some special case fix thus it will break with upgrades. Also new major upgrade tends to pull in minor bugs into huge tetex package. Thus these will cause FTBFS (RC) bugs on many documentation packages whose maintainers are not always ready for making complicated adjustment to TeX upgrades. Recent changes to TeTeX 3 was easier than woody days. For example, when I got FTBFS RC bug due to tetex, I reassigned it to tetex. I should have reduced severity but I did not do it partly because of my wish to get Frank's attention and his assistance to fix it from Tetex package. Sorry. This may be the reason Frank felt about FTBFS/RC. It is not FTBFS for him and that was not RC for him. I wish that tetex upgrade happens more like gcc upgrades. So testing both versions are much easier and, if needed, we can specify older version ones. Much worse, there are a couple of cases where we had to NMU the packages, either because the maintainers where inactive, or in one case because he said no time here, just go ahead. Except for this one case this couldn't have been done with the packages in experimental, since failing to cooperate with a package in experimental isn't RC, is it? Not only do you not have to have an RC bug as an excuse to NMU; but uploads to experimental (which these presumably would be) have even less need for care and caution. Of course, in principle, we could have created our own compatible_with_teTeX-3.0 repository and uploaded fixed packages there, and do all the testing there. But then I don't understand what unstable is for... Generally, experimental fits the above role. Unstable's for uploading new development of packages that will hopefully work, but might turn out not to. In particular, though, they need to be fixed pretty quickly -- six months in experimental, and another two so far in unstable isn't quickly. I agree. Yes, the problem is that bugs in other packages keep popping up slowly. Like #341849 in debiandoc-sgml: We already had checked that debiandoc-sgml didn't have one of the usual incompatibility bugs, but then it turned out that there is still one, which is only triggered when a far-east document is typeset in a certain encoding. It was FTBFS for documentation packages which used debiandoc-sgml. A far-east document is typeset in a certain encoding doesn't sound like an RC bug; and therefore not something that should hold up transitioning to testing. Certainly, fix it ASAP once it's found, but that's the desired result for any bug. Exactly. I should have reduced severity. ... That would be bad, but I can't see how I can speed up tetex's evolution to be releasable by letting it rot in experimental. That's true; the idea isn't to let it rot in experimental, it's to have a quick pass through experimental that catches the most obscene bugs, then to put it in unstable where you catch a few more, then to let things progress to testing naturally, if necessary by having the RMs remove tetex related packages that aren't getting updated to the latest version in a timely or successful fashion. I think one to ease tension is to make tetex packages to coexist in archive just like many gcc. Current strict FTBFS rule will likely to make many documentations provided only in HTML, I think. Because fixing TeTeX related PDF/PS generation issues are quite difficult with short notice without tetex maintainer helping us. (They usually do.) We do not have soft and slow transition like gcc. I hope situation will be better soon but I am still struggling why debiandoc-sgml-doc fails to build nicely. (Yes, I know I can get by by
