On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote: > On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote: > > But like I said, elog messages are already saved in > > /var/log/portage/elog/$cat/$pf so people can > > read these. Isn't this the same with what you suggest? > > Is that by default? And when was that default added? > > I certainly do not have /var/log/portage/elog/$cat/$pf on my machine > (using portage-2.2.0_alpha149), and in fact have never heard of this log > file before your email. > >
No, they are not saved there by default. They must be enabled. elog messages are not saved there, those are the build logs. They are saved in /var/log/portage/elog/ as for example: app-portage:gentoolkit-0.3.0.7:20121216-000453.log PLUS, they can be cleaned by emaint or setup to be auto-cleaned by emerge as well so as to not fill up the system with old build logs. emaint -p logs the default is 7 days old, will be cleaned. The emaint log module also takes a -t, --time option. Pacho was right with his original email. It would be best to install that small text file of info where it can be found for reference later. I have often had to go searching ebuilds for elog/einfo data about configuring some pkg for such and such long after it's first install due to needs changing or some breakage of some kind. Much like our gentoo handbook, where most of that info can be found elswhere on the net, this would extend to pkgs so that that info could be compiled together in a place that did not require net access to find key info needed. This proposed method would not apply to all those pkgs with over use of elog/einfo either. Many of those just need to use has_version() to reduce the noise. But there are many such pkgs in the tree that could benefit from the dev putting together a small doc of the configuration info for gentoo, put it into the files dir to be installed as Pacho suggests. It would likely reduce the number of bugs submitted due to bad configuration and make it easier for users to locate (after some time to get use to the idea where to find them). -- Brian Dolbec <[email protected]>
signature.asc
Description: This is a digitally signed message part
