Can ebuild conficuration items be concatenated in a total report Reproducible: Always Steps to Reproduce: 1.na. 2. 3. Currently the is a HUGE heap of output output if the result of emerge is installing several packages.It would help if there is a facility that would get all configuration manual postprocessing tasks so that after an emerge all manual postprocessing can be requested just like the updating of config files can be done separately?
You mean elog/einfo messages should be stored so they can be read at a later time?
Yes but ONLY the ones concerned with crucial config or setup messages. not the generic chitchat or error messages. (logging for failed services itn't too hard. But how to get one einfo in a setup of 2000+ ebuild with 900+ results that are full of all kinds of data. like these instruction from postgresql server: pkg_postinst() { postgresql-config update elog "The time stamp format is 64 bit integers now. If you upgrade from older" elog "databases, this may force you to either do a dump and reload or enable" elog "pg_legacytimestamp until you find time to do so. If the database cannot start" elog "please try enabling pg_legacytimestamp and rebuild." elog elog "The Unix-domain socket is located in:" elog " ${EROOT%/}/var/run/postgresql/" elog elog "If you have users and/or services that you would like to utilize the socket," elog "you must add them to the 'postgres' system group:" elog " usermod -a -G postgres <user>" elog elog "Before initializing the database, you may want to edit PG_INITDB_OPTS so that" elog "it contains your preferred locale in:" elog " ${EROOT%/}/etc/conf.d/postgresql-${SLOT}" elog elog "Then, execute the following command to setup the initial database" elog "environment:" elog " emerge --config =${CATEGORY}/${PF}" }
I think all of that is already covered in the make.conf(5) documentation. You would be looking for mentions of "elog". You can mail it to yourself, store it separately or among the other log files you keep, and so on.
That would still amount 2880+ mails to wade through. I don't know where my previous 900+ came from ( I must have clicked on the wrong window) because the /var/log/portage directory on that system (2000 and a bit packages emerge -1e world) actualy are ~3260 log reports. for only one or two hits... BTW i allready do use elog to report to a jabber server. but it's too easy to overlook one or two messages... when screening ~3000 messages Debian allready has a separate configuration option in the dpkg system.
(In reply to comment #2) > Yes but ONLY the ones concerned with crucial config or setup messages. Maybe you're looking for /var/log/portage/summary.log. You can also use the PORTAGE_ELOG_CLASSES variable to control which kinds of messages are logged. There's an example in /usr/share/portage/config/make.conf.example.
Ok save_summary would help. Would it be possible to have the summary filename contain the date/time yyyymmddThhmmss of the tie the emerge starts so that doesn't need to be done manualy? Also it might help is there would be and elog class config which would allow a summary of pkg_postinst output. Q, from the description it isn't clear if info could be collected in a summary and errors could be collected in idividual files..?
(In reply to comment #6) > Ok save_summary would help. > Would it be possible to have the summary filename contain the date/time > yyyymmddThhmmss of the tie the emerge starts so that doesn't need to be done > manualy? Here's and example of the timestamps it already contains: >>> Messages generated by process 11617 on 2011-05-13 14:29:50 PDT for package kde-base/konqueror-4.6.3: LOG: postinst If you want to use konqueror as a filemanager, install the dolphin kpart: emerge -1 kde-base/dolphin:4.6 > Also it might help is there would be and elog class config which would allow a > summary of pkg_postinst output. > > Q, from the description it isn't clear if info could be collected in a summary > and errors could be collected in idividual files..? The closest thing that we have to that now would be to do something like PORTAGE_ELOG_SYSTEM="save_summary:error", which would cause summary.log to contain only error messages. I suppose we could add finer-grained configuration support. As another option, you could use a tool like app-portage/elogv or app-portage/elogviewer to analyze the logs.
I meant: summary-20110514T160510.txt as a name where the emerge started on 14th of may 2011 at 16:05:10. Then there is an indication of what run caused what output. The problem is that for the pkg_postinst output the einfo (==> everything) is logged and not errors ... And I understand what I can do, the request was meant as an enhancement request to the current system, which gives a lot of control, but isn't perfect. I also understand perfection is never reached but it is something to try to reach. So i do not exactly agree to 'resolved'/'worksforme', currently it can work for me, but it can be done better. 'confirmed'/'todo' would be better..;-)
(In reply to comment #8) > I meant: summary-20110514T160510.txt That could easily be implemented by copying the save_summary module and modifying it to start a new log for each emerge process. A global variable could be used to make the log file name persistent for each emerge run. > So i do not exactly agree to 'resolved'/'worksforme', currently it can work for > me, but it can be done better. 'confirmed'/'todo' would be better..;-) Ok, re-opening and removing jer from cc since he's probably not interested in the rest of this bug.
Ok Thanks for considering, if you need a tester I will accept that challenge. If you meant that i need to make it it will take some time as i'm not proficient in python. And have no knowledge of the inner workings of portage.
too old to continue..