"Maciej (Matchek) Bliziński" <[email protected]> writes: > No dia 16/01/2013 19:02, "Peter FELECAN" <[email protected]> escreveu: >> >> "Maciej (Matchek) Bliziński" <[email protected]> writes: >> >> > 2013/1/16 Dagobert Michelsen <[email protected]>: >> >> The new link symbol inspection is in place for some time now, maybe it > has >> >> some serious drawbacks on database access? >> > >> > Some packages produce metadata objects serializing to more than 32MB. >> > The out of space error could be a memory leak which I have been >> > fighting over the weekend, but did not manage to find the cause. In my >> > case, I was trying to run a full catalog import. >> > >> > Peter, what operation is causing the out of space error? How much RAM >> > does the machine have? >> >> The "out of space" issue happened when packaging the *huge* TeXLive >> hundred packages on the Baltic Online build farm; I think that you know >> better than me how much RAM unstable10s and its companions have. I'm >> trying again but one cycle merge-package is long: I start the process in >> the morning and have the results the other day. You can see the log of >> the action in progress in ~pfelecan/logs/texlive > > Maybe Yann can look at the logs and figure out what was the immediate > problem. The main issue is that we art collecting way more date than > previously, and that puts more pressure on the database. Do you think they > the problem you had I'd transient? If it's persistent, we can back out the > changes and stop collecting the additional data. I would prefer to > gradually solve the performance problems without having to roll back, but > if people can't build packages, we will have to.
Th issue is not transient as I repeated 3 times the operation. However, having a more important disk quota will delay it. > I did rebuild GCC with the new code and GCC is a pretty hefty build. But > maybe TeX live is so large that it pushes the system off the cliff, while > GCC is still small enough. The difference is in the number of files and, among them, the number of binary executable files which are all candidates for the new checks. > Yann, maybe we can selectively disable the ldd and elfdump data collection > for packages that wish to have these checks disabled? The checking code > would need to allow for missing ldd and elfdump data. Since all that > checkpkg sees is the package file, there would have to be a specific bit of > information in the package itself that would instruct checkpkg to skip ldd > end elfdump. It could be in pkginfo for example. This is an interesting option but I suggest to make it temporary, i.e., until solving the issue. How do you think to set this option, obviously in the recipe. -- Peter _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
