Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
Hey devs, the work is finally done - and it works flawlessy (at least on my box at work). Here is how i added it: 1) A new variable has been added to /etc/make.globals: ELOGFILE. This variable holds the current logfile. It defaults to "/var/log/emerge.inst.log". 2) I added a new class to "portage.py": instlog. This class handles the maintenance of EINSTLOG. It has two relevant functions: dump() and flush(). dump() dumps ELOGFILE to stdout. flush() wipes all content from the ELOGFILE. 3) Modification to ebuild.sh: I had to add a var called ELOGGING. This defaults to "no". If we run into a pkg_preinst or pkg_postinst, ELOGGING is set to "yes" 4) Modification to functions.sh: einfo() and ewarn() are modfified to write to ELOGFILE when ELOGGING is set to "yes" 5) Added flush() and dump() to depgraph.merge() In a nutshell: - user types "emerge foobar". - ELOGFILE is set to "/var/log/emerge.inst.log (make.globals). - /usr/bin/emerge runs into merge(): the ELOGFILE gets flushed with flush(). - /usr/bin/emerge happily merges around and calls /usr/sbin/ebuild.sh - if we run into a pkg_postinst() or pkg_preinst(), ebuild.sh sets ELOGGING to "yes" or "no". - /usr/sbin/ebuild.sh calls /sbin/functions.sh. - /sbin/functions.sh drops the output into ELOGFILE when ELOGGING is set to "yes" (that means, it drops the output when we run into ewarn/einfo in pkg_postinst/pkg_preinst). - /usr/bin/emerge finishes because mylist[] is done. - /usr/bin/emerge uses dump() to dump the ELOGFILE to stdout. Well thats it. Give it a try - i will attach the 5 files (ebuild.sh,emerge,functions.sh,make.globals,portage.py) tar bzipped. Thats the way to install it: $ tar jxvf foo.tar $ cp ebuild.sh /usr/sbin/ebuild.sh $ cp emerge /usr/bin/emerge $ cp functions.sh /sbin/functions.sh $ cp make.globals /etc/make.globals $ cp portage.py /usr/lib/python2.2/site-packages/portage.py Use it and you should see something like that right after "clean": ------- | >>> These messages have been logged to /var/log/emerge.inst.log : | * $PN: message | * $PN: message ---- (BTW, "emerge gentoo-stats colortail" is nice for testing - doesn't take long to download/install it and produces quite some output) So what do you say? -phoen][x-
Created an attachment (id=6039) [edit] portage-modified.tar.bz2
*** Bug 4138 has been marked as a duplicate of this bug. ***
Created an attachment (id=6046) [edit] patches.tar.bz2 Okay i'm evil. I forgot the patches. :( Here they are. -phoen][x-
Wouldn't it be handy to also save them permanently (in a second file)?? That way you can see all of them after you have done several emerges in a row or for future reference? It shouldn't be too hard to implement I guess.
Heyas Sam, the file would fill up pretty fast. And it would need user interaction (eg "rm /var/log/emerge.inst.log") to ~clean~ it up again. Sorry, but I dont think that this is a good idea. This very information we log at the moment, isn't really interesting for more like 10 minutes IMHO. You read the info and follow the instructions. The next merge places new instuctions in the file. That's how i wanted to implement it, and that's how i implemented it. :) However, if one of you (/me looks at the Cc: list) likes Sam's idea, try to explain me why we need it and i'll add it. -phoen][x-
I haven't tested it yet, although the basic scheme looks sound. What happens if the user hits <ctrl>-c during emerge? Will the already-generated log messages be displayed?
*** Bug 12202 has been marked as a duplicate of this bug. ***
*** Bug 13577 has been marked as a duplicate of this bug. ***
Great. I would find it nice too, if a permant log could be enabled by option (by command line or config). This would be nice for automated emerge's. One reason: It's not always possible to emerge all needed things on line. E.g. I can't do 'emerge postfix fcron' on one line, because fcron needs an mta and therefor ssmtp is choosen, but that conflicts with postfix. There are more such problems (e.g. global use-flag sasl, but I have to emerge squid with USE="-sasl" because squid wants saslv1. But collecting einfo and ewarn messages are great feature I allways missed. Thanks for that.
Sorry for that long line, I don't know how I've done this. :(
*** Bug 14302 has been marked as a duplicate of this bug. ***
*** Bug 15206 has been marked as a duplicate of this bug. ***
I agree that a more permanent collection would be nice. Personally I often get into trouble because I do emerge -u world. If several packages are being emerged I never get to see the ewarn or einfo messages belonging to the packages in "the middle". Perhaps a feature to buffer up the messages and less them at the end of the multiple emerge?
I vote that this would be a very nice feature as well.
*** Bug 21525 has been marked as a duplicate of this bug. ***
This enhancement seems pretty popular, is any work currently been done on it or being planned. Design, programming, or otherwise?
*** Bug 22471 has been marked as a duplicate of this bug. ***
I didn't know this bug.. I've made a patch (#22471) which is very simple. Can you guys look at the bug. But this patch looks good as well :) I think if we make a logfile, it should be separated files. example 030609_01_info.log yymmdd nn nn=number of emrging of day. Then after emerge it should say "You got messages during emerge. Please look at /var/log/somewhere/030609_01_info.log" Sorry, my poor English :)
*** Bug 24913 has been marked as a duplicate of this bug. ***
*** Bug 25256 has been marked as a duplicate of this bug. ***
*** Bug 18079 has been marked as a duplicate of this bug. ***
+ echo -e "${WARN}* ${HILITE}${P}${NORMAL}: ${*}" >> ${ELOGFILE} This is the first thing that caught my eye: The variables ${WARN} , ${HILITE} and ${NORMAL} all specify bash escape codes for color and should not be written to a text log file.
+ def dump (self): + """ + Dumps the logfile to stdout. + """ + print ">>> These messages have been logged to",self.elogfile,":" + self.open(mode="r") + for line in self.mylogfile.readlines(): + print line, + self.close I'm assuming this is a typo, it should probably be: self.close() (this isn't really critical as python will take care of closing it, due to reference counting *I think*, but anyway...) Also, when will the flush function be used?
I would like to see a similar feature: emailing of important emerge messages to root. I've written a small patch to do just that, which I'll attach directly. The major flaw with my patch is that you get an email for every invocation of einfo, ewarn, or eerror. Perhaps my approach is the wrong way, and instead we should log everything then at the end of each emerge simply mail the log to root. What are the chances of getting this functionality worked into this whole mess as well?
Created an attachment (id=16300) [edit] patch for functions.sh implementing emergemail feature to try it out, set FEATURES="emergemail" and try an emerge that has some einfo or ewarn messages.
the mail thingy is used in debian too, i like the idea
Created an attachment (id=16341) [edit] updated functions.sh patch With some lovely advice from Karsten Schulz on gentoo-dev, I managed to remove the previously noted nasty limitation of my implementation. Now you get all the einfo messages in one email (if there were any), all the ewarns in one, etc. I've used it on a couple ebuilds and it works quite nicely. Please try it out and comment. To try it out, you might do.. % cd /sbin % patch < /home/me/functions.sh.patch % emerge stuffit (stuffit chosen because it has no deps and it fails immediately with an einfo)
I forgot to mention that you have to add "emergemail" to FEATURES in /etc/make.conf. So that's: % cd /sbin % patch < /home/me/functions.sh.patch % $EDITOR /etc/make.conf # add emergemail to FEATURES % emerge stuffit (stuffit chosen because it has no deps and it fails immediately with an einfo)
I testet the new functions.sh with the following ebuilds: app-benchmarks/dbench (einfos) app-emulation/vmware-workstation (einfo, ewarn) app-emulation/point2play/point2play-1.0.1.ebuild (eerror) After that, I emerged -U --deep world: [ebuild U ] sys-libs/db-3.2.9-r7 [3.2.9-r2] [ebuild U ] app-editors/vim-6.2-r2 [6.2] with some einfos from db and vim without any problems. It works for me. Karsten
With exim i had to patch as follows below. I wonder if there is any clean solution for this that works with all mta's ? Or maybe it's only exim that is problematic... --- patch lookalike begins here: (Excerpt starts at line 1136). [ -z "${CCACHE_SIZE}" ] && export CCACHE_SIZE="2G" ccache -M ${CCACHE_SIZE} &> /dev/null fi + if has emergemail ${FEATURES} &>/dev/null; then + addwrite "/var/spool/exim/input/" + addwrite "/var/spool/exim/msglog/" + fi fi # "$*"!="depend" && "$*"!="clean"
I see, this could be a problem with other MTAs. If people with courier, postfix, and sendmail could post patches as well we'd have decent coverage. I'll piece the patches together and post the results. Can't do it until I get back from a trip this weekend. Mondayish.
You could stick to SMTP mailing. While you are at it, you could also add EMERGEMAIL_SERVER and EMERGEMAIL_MAILTO (would make sense to use default values like 127.0.0.1/root in make.globals). This would provide a clean interface to all MTA's, since SMTP is standarized in an RFC. Furthermore, it would not require a working local MTA (since you can use EMERGEMAIL_SERVER in make.conf to override the SMTP server). Only an idea. -phoen][x-
emergemail works well with postfix MTA. My tests (see comment #29) were done with postfix installed on my system. But i like to encourage you to consider phoenix' suggestion to use smtp (at least as an additional option) have fun! Karsten
I have found two more issues. Issue 1) _Occasionally_ i get a mail looking like this: information from emerge of gcc-3.2 From: abuse@isp.com <-- not my real adress ... To: CFLAGS="" CXXFLAGS="" ----------------- This happens for gcc 3.2,2.95.3 and xfree 4.2.1 It seems to have something do do with doing emerge --pretend --update --deep world after having done rsync. But I'm not sure yet. Maybe it's the rsync. Issue 2) epatch uses info so all packages that uses it to apply patches sends me a mail telling me this. I feel this information is unecessary and that maybe the eclass which epatch is in should be changed or that the messages should be filtered.
see also bug #2834
Okay.. I'm struggling a bit switching over to SMTP mailing. I can do it with telnet, but telnet is not default install in gentoo. Is there another way to do SMTP mailing from the command line, without necessarily having an MTA? Otherwise I can submit a patch with telnet SMTP mailing, based on EMERGEMAIL_SERVER and EMERGEMAIL_MAILTO as was suggested.
*** Bug 28397 has been marked as a duplicate of this bug. ***
*** Bug 29751 has been marked as a duplicate of this bug. ***
please add this feature asap, maybe including mailx feature to mail root
Please consider people who are installing the system from scratch. Sending email to root during a base install is somewhat pointless. Of particular concern to me is that early emerges can pull in dozens of dependancies, some of which may generate their own messages. I had gone quite a way down an initial install before I noticed any of these messages (they aren't mentioned anywhere in the docs that I have seen). Since some of them seemed quite important, I decided to re-install everything from scratch, redirecting all emerge commands (including 2>&1) to individual log files (disk space is cheap). This way I could browse the files afterwards looking for these potentially helpful messages. Note that when logging command output that you must append if a log file is already there. See bug 31177 for an example where that wasn't done inside genkernel.
I got an idea, how about making portage write the info to a file(one for each ebuild that writes info) in /var/log/portage (or some other place), and then point the user to read the info from those files after the emerges have completed?
Failing more sophisticated fixes, a possible quick and dirty interim fix is to mark all important messages with a characteristic text string, such as an initial #####. The the "Find in History" option can be used in the screen build log, or the entire log can be tee'd to a file which can be searced trivially by most editors. I'd be really happy to see a fix of some sort - I'm *sure* I'm missing important stuff on "emerge -u world".
*** Bug 32358 has been marked as a duplicate of this bug. ***
Have anyone considered ncurses for displaying messages during install? You could create a window with a confirmation dialog for each message.
confirmation requires interactivity which breaks the general non-interactive rule for emerge, so it's not a viable option.
This improvement is in the air. Publish early, publish often. Please put it in production tree, and let's see what happens.
*** Bug 34856 has been marked as a duplicate of this bug. ***
(assigned from Bug 34856) Sorry for asking, but I just don't get the technical point at the moment: Is this intended to show messages from pgk_setup _before_ emerge takes place? (see mozilla-gtk2 vs. galeon-gtk1 problem) Or if not, would it be possible to use it for that like: 'display pkg_setup' 'countdown 10 seconds (chance to hit ctrl+c)' 'normal emerge' TIA
Is it not possible to use ncurses to stack dialogs? Just keep them there and continue merging.
*** Bug 35575 has been marked as a duplicate of this bug. ***
Just had a question about the portage-modified.tar.bz2 ball when following your instructions about where to copy things: Thats the way to install it: $ tar jxvf foo.tar $ cp ebuild.sh /usr/sbin/ebuild.sh $ cp emerge /usr/bin/emerge $ cp functions.sh /sbin/functions.sh $ cp make.globals /etc/make.globals $ cp portage.py /usr/lib/python2.2/site-packages/portage.py I found that inside of ebuild.sh it looks at: if [ -e /etc/init.d/functions.sh ] then source /etc/init.d/functions.sh > /dev/null 2>&1 elif [ -e /etc/rc.d/config/functions ] then source /etc/rc.d/config/functions > /dev/null 2>&1 fi and so it is looking for the new ebuild inside of /etc/init.d/ when you said to place it in /sbin/ Did I miss something here?? I fixed this by cp /tmp/functions.sh (new file from tar ball) /sbin/functions.sh.new and changed the lines about /etc/init.d/functions.sh to point to the /sbin/functions.sh.new (.new as to keep my *working* function.sh working. Well just thought I would give some user feedback ;-) Jeremy G.
*** Bug 38397 has been marked as a duplicate of this bug. ***
*** Bug 36467 has been marked as a duplicate of this bug. ***
I'm attaching a revised functions.sh.patch that alters the sendmail stuff to stop mail clients showing "To: undisclosed-recipients: ;" (I use kmail).
Created an attachment (id=25855) [edit] updated functions.sh.patch
*** Bug 43191 has been marked as a duplicate of this bug. ***
I'd vote for this feature as well. Any plans on when this will be implemented officially?
Why not use the python smtplib to send e-mail through any SMTP server? I'm attaching a simple mailsend script that will send the specified file to the recipient from the sender using the specified host. USE: mailsend filename sender recipient host "subject" (subject isn't being sent for some reason. Not enough time to look at it right now) Maybe the scripts could be modified to use something like this mailsend instead of a local MTA.
Created an attachment (id=27224) [edit] Python script to send file by e-mail (uses smtplib)
My concern about this would be if something like this is put in the scripts, there still has to be a way to send to a local user with an mda or something.
Should be simple enough; a variable in make.conf (oh no! Another one!) detailing which local user or e-mail address to send mail to.
mailsend accepts arguments: filename sender recipient host subject So if you need to send the contents of a file to a local user you just need to pass the local user as recipient and localhost or 127.0.0.1 as host and the mail will be sent using the local MTA. The advantages of doing this through SMTP are 2: 1) it will work no matter which MTA is installed on the host. 2) if no MTA is installed, the user should be able to set a different mail host. Regarding Stewart's comment, two variables should be set: mail recipient (local or remote) and mail host (which could default to localhost). Sender and subject should be automatically generated.
Created an attachment (id=27382) [edit] Python script to send file by e-mail (uses smtplib) The subject is now sent correctly. It was a stupid mistake.
Sending mail assumes that someone is going to read it. Most of the time, they aren't. It's junk. Most machines probably have no MUA anyway. It would be far better (simpler, easier to write, easier to read, easier to grep) to write a numbered logfile in /var/log somewhere.
Granted, but with every option comes the notion that they are "optional" :P I do like the idea of a log file regardless of the e-mail functionality - I just like the notion that a daily / per-merge log could be mailed to me. With the user / mailhost variables, it could be sent anywhere, even somewhere like Hotmail or Yahoo.
*** Bug 45664 has been marked as a duplicate of this bug. ***
*** Bug 47910 has been marked as a duplicate of this bug. ***
Please incorporate Owen Gunden's excellent "emergemail" (Comment #25) patch into Portage - I have to keep repatching functions.sh.
*** Bug 51823 has been marked as a duplicate of this bug. ***
The script in comment #55 works great. I wish I had this one installed on my sun u10 before silo got updated... The system coudn't boot any more, because silo has not been executed, but it was mentioned in an ewarn (which scrolled by during the update of more than 30 packages). Who is currently in charge of maintaining this bug-report? It would be great, when it becomes included in Gentoo 2004.2
Hey, 57 persons are in CC. The bug is there since 11-2002. 21 duplicates have been filled The proposed patch will soon blow a candel Machines keep crashing for their maintener don't see the ewarns Don't you think it's time to do something about it (and I don't talk about WONTFIX) ?
the feature kind of already exists with PORT_LOGDIR but no one has mentioned that fact
PORT_LOGDIR logs the entire build process. This processed a email of the ewarn itself.. There have been patches submitted but they won't include it in the source tree.. Thats the problem.
A log dir of all commits is not the same like an email about the einfos/ewarns. Administrators should receive a (short) note on their desk that something has changed instead of pulling it manually out of the directory. So, if it is already implemented, why is the email-script missing?
Well, for one thing, the default Gentoo install does not include an mta or an mda. (Similarly, methods that rely on syslog are also problematic, since a syslog daemon isn't installed until one of the last steps of the install process.) Given those facts, I don't think that anybody has managed to sell the portage team that the current patches are the "right" solutions to this problem. My personal opinion is that the "right" solution would be to: (a) create a new function (or extend einfo / ewarn) that would be called in ebuilds to log important text to a log file for just this purpose (b) Modify portage to collect all of the information that has not yet officially been presented to the user and either spit it all out at then end of the emerge, or e-mail it to a particular user, or just leave it as is in the log file (with the user choosing between those options by using appropriate FEATURES settings). (c) Fix all ebuilds in portage to use the new system appropriately (d) Ensure that the new portage code is robust to <ctrl>-C's, power failures, etcetera. This "solution" requires a lot of work, though, and it still lacks the important step of selling the portage team on the idea that it is more important for them to work on this problem than it is for them to work on the myriad other significant bugs in portage.
I beg to differ. They don't have to work on anything. If you read threw this laundry list, there were patches made for this. it was just a matter of them adding it. Not writing it. And this was added as part of the features line, with variables in make.conf for how to send the email.. This has already been thought off. my question is why it didn't get added.
which patch? functions.sh belongs to baselayout, not to portage. I haven't looked at the tarballs, but I'm sure they won't apply to current portage code anyway. Also, do you really want one mail per einfo/ewarn statement (it's possible for them to be called in any shellscript) and all mails sent to root with no option to change that (I'm sure when we add this the request will come)? The patch only focuses on mail notifications, but there are several other solutions (delayed display, message queue, syslog, ...) What I want to say is that this issue needs a generic solution, not a specialized one.
I don't believe this. This is a very real problem which could be so easily solved. To say it can't be done because it's not a perfect solution is just daft and only ends up with Debian-like delayed development. Yes it is specialized... there is a specific need! Is Gentoo not about choice? What actual harm would be caused by adding this as a FEATURE, with a comment warning about it's requirements and the fact that all einfo/ewarns would be mailed? functions.sh is indeed in baselayout and appears to log all ewarns to syslog as the facility "rc-scripts". Since when was portage an rc-script? I for one would find an email far more useful than a syslog entry (push rather than pull). If the patch in #55 causes portage to break, say so and something can be done about it. Otherwise, please include it.
I attempted to apply the "updated functions.sh.patch" to functions.sh in the ~x86 baselayout so I could see how this works before I comment and got the following message: "malformed patch at line 57" What did I do wrong to get this message?
Re: #79... That's hardly surprising - look at the first line: --- functions-old.sh 2003-08-18 21:49:35.000000000 -0400 There have been a lot of changes to functions.sh since then. You can still manually patch it in an editor and it works. Just paste the first lot of additions at about line 325, before this line: # void esyslog(char* priority, char* tag, char* message) ...and the rest will be obvious. I don't want to keep updating the patch because the negative response to this bug would mean I would be forever doing that.
To fix the patch, change 53 in the third line to 54. As for the rest of it, at least for me email is a perfect solution, since procmail allows to do whatever I want with it (log to a file, send to someone else, etc.) I was looking for something like this for some time.
I agree with the previous comment in this bug that functions.sh is not part of portage. Because of this I'm not sure that we should be patching functions.sh for a portage specific feature. What I would like to do is look into reworking the patch that is provided in this bug and patching ebuild.sh instead. Also, I like the idea of using the mailsend script that is included in this bug to send mail, that way we aren't depending on the existence of a sendmail program. My thought is to look into patching ebuild.sh and using the mailsend script instead of calling sendmail. I will propose a patch once I have this done. What do you think?
Do not post to this bug again if you aren't fully aware of the following comments. The best way to get this bug ignored or closed is to make it unreadable/unfollowable. Comment #72 -- PORT_LOGDIR Comment #75 -- Design and Reasons Comment #77 -- Options and issues I will _never_ accept odd patches. If someone reports that it's flawed, it will be ignored. If you really want this feature, work it out into something that is a very clean, very small patch that affects nothing beyond it's target and doesn't do things that are insane like mailing 500 messages to the admin. If there is a flaw in your design, I will pick at it. The cleaner you make the additions, the less time you'll have to spend explaining why your solution is legitimate and reasonable. http://www.gentoo.org/proj/en/portage/index.xml Read sections 8 and 9. They mention most of this. Potential help for a better design: ${T}/something can be used to store entries. It should remain until the merge completes. Binaries will never see anything prior to pkg_preinst. One screen of e{info,warn,error} is up to 24 distinct messages. Some systems will not have an MTA. Some systems will not have an MUA. Some systems will not have a logger. If you have tried all possibilities to break your patch, and have found nothing, you may posting it here with descriptions of what you have done to test and the description of the patch and design. =========== Continued flaming in this bug will get it closed, and it will then be completed whenever the portage team gets around to it. We do not have time to deal with complaining of this magnitude. Help out in a useful way, or be quiet. Trying to help is great. Even if your patch or solution isn't accepted, you or someone else may become inspired to make something better. ===========
*** Bug 54623 has been marked as a duplicate of this bug. ***
*** Bug 55081 has been marked as a duplicate of this bug. ***
*** Bug 57661 has been marked as a duplicate of this bug. ***
I just returned from two hours of hunting an error after -u world which I finally solved by manually checking the ebuilds for einfos manually. I don't want to be impolite, but why hasn't this been included yet? Users are continiously requesting it and I don't want to know if an invisible einfo already caused massive system damage.
Although I also would love to see such a feature in Portage, there are at least some tools that can provide similar things, take a look at http://forums.gentoo.org/viewtopic.php?t=67849 .
*** Bug 21392 has been marked as a duplicate of this bug. ***
Created an attachment (id=36713) [edit] Ebuild einfo/ewarn/eerror sent to syslog Patch against: sys-apps/baselayout-1.9.4-r3
Just uploaded a new patch regarding this functionality. This patch simply logs the einfo/ewarn/eerror output. This should alleviate many of the concerns expressed with previous patches, including: log file size, output log persistence, sending emails, enabling/disabling output. By sending the output to the system logger, you can configure your system logger to handle all of these issues, just like for any other system log events. Facility: user.info, user.warning, or user.err Program: ebuild Output format designed to allow simple regexp matching for further log redirection or searching.
I am working on a patch to do this also. However, I believe this should be done in portage itself, and not in baselayout since it is a portage specific function. The approach I am working on is to patch ebuild.sh with custom versions of ewarn, einfo and eerror which display the messages and log them to a file, then I will need to figure out where in portage to write the code to actually send the email.
so many duplicates... we should probably change this bug summary name to catch those search terms... (bug within a bug!)
Please do not use email or syslog, or else make them configurable options along with a normal file log option. Any solution to this problem must deal with bootstrapping the initial install as well as systems that do not have an MTA or logger loaded. The current system using PORT_LOGDIR almost works, but it would be real nice to split out the einfo/ewarn/eerror output from the compile and install messages. Another deficiency of PORT_LOGDIR is that not all of the information sent to the terminal is logged. Please re-read comment #83.
Can I just offer my $0.02. Logging to file should be the default. Email should be configurable. But even if emails are configured, always log to file (emails can go missing, after all) IMHO, full einfo/ewarn should NOT go to syslog, but at most a one-line entry in syslog saying "new ewarn info added to file ... for package ..." should be made. One line for each package. I'm not sure whether einfo should be added too. Perhaps instead of syslog, logging to /var/log/emerge.log? Rather than saying log to syslog|email|nowhere, make each option configurable. So you can hav all turned on if you like. So, configuration options would be: email address (optional; maybe default of root@localhost) level of email reporting (none|ewarn|einfo) (default none) level of syslogging (none|ewarn|einfo) (default none) level of emerge.log logging (maybe we need a better name for this?) (none|ewarn|einfo) (default none) One last thing: (it may not be my place to say this, but that won't stop me :-)The status of this bug is still NEW, but it seems that a lot of stuff has been written. Assigning it to someone might make things move along a little more quickly.
Best would be absolutely no email support. Adding it would require a dep from sys-apps/portage on virtual/mta, which is not an option. If the einfo messages are logged to a file, anybody who needs them emailed would be able to write a script to get it to happen automatically - especially if a notification is syslogged. As for ease of use for users, such mail support would go into a different tool rather than portage itself. At least that is the case until portage is modularized enough that it can support a use flag for the dep.
Also, forgot to mention that creating a /var/log/portage directory will make portage log all output of each emerge to individual files. Using /var/log/emerge.log to know which files to check in /var/log/portage (or even some find -mtime magic) allows you to get at this information fairly easily. Addendum to the previous comment: mail support in portage is fine as long as it uses python to open an smtp connection a configurable server to send the mail.
As I am one of the people, if not the only person, that requested email support, then I am happy for initial support to just include logging. As long as any important output is available after the emerge has completed, then I will be happy enough. I can always knock up a script to tell me when the file has changed, but I'll probably look at it 1) from time to time and/or 2) after an emerge and/or 3) (more likely) just when things go wrong.
Why would it *require* a dependency? I don't see portage depending on distcc or cvs, and they're both used when FEATURES is set accordingly. As I see it, the "proper" way to do this, would be to add a FEATURES flag, such as "elogging", along with an ELOGGING_TYPE flag in /etc/make.conf that can be set to one or more of mail, syslog or file. In the case of mail, ELOGGING_ADDRESS could specify the recipient. In the case of file, ELOGGING_FILEDIR could specify a directory to log to, or specifying 'file' could simply indicate that you want to log einfo/ewarn to PORT_LOGDIR. Personally, I think this stirs things up too much to happen, so a simpler alternative: Could PORT_LOGDIR be used? It could be extended to support more than one target, comma or space delimited. If a target starts with a /, it's a directory to log to. If it starts with mailto:, it's an address to send mail to via the system MTA. We still need to be able to specify the "log level", such as full emerge logging (as PORT_LOGDIR does now), or just einfo/ewarn logging (most useful to 99% of us). Whatever is best, I would do something like: PORT_LOGDIR="/var/log/portage,full mailto:mal@komcept.com,einfo" With full as the default if none specified (allowing current make.conf's to continue unhindered). If comma is a problem in paths, another character can be used or it can be backslash escaped. Whether or not an mta/logger are present are largely irrelevant. A simple comment in make.conf should stop newbies from trying to log bootstrap einfo/ewarn to syslog or mail. A simple check for the existance of /usr/bin/sendmail, or indeed by using python's own SMTP API is enough to avoid total failure. It would also not be hard to fall back to file logging, if PORT_LOGDIR is set, but no MTA is found. Again, it's all about choice. You don't have to log to mail, and those admins who do, will do knowing full well that mailing may cause emerge delays, or that the mail might not get there. However, I would bet that 99% of the time it will be mailing a local domain anyway. I apologise for the length, it would be good to find some common accepted method. Please comment.
To me, email all is the best answer. I continue to use emergemail (Comment #55), repatching functions.sh as necessary. It has saved my bacon numerous times.
Let's not invent the wheel when there's a fully configured SUV already parked in the driveway. Regarding using a logger: IMHO, this is the right way to address the problem. True, there may not always be a logger installed, such as in a bootstrap installation situation, but the need for logging during this phase is arguably minimal: Logging is much more useful for maintaining an existing system and knowing when your world updates internally contain recommendations for a revdep-rebuild or advise of conflicts or changes. And it's easy for the patch to just bypass logging if there is no logger present; my posted patch already does this. Regarding using an MTA: This is where the logger is useful. 95% of all system loggers are configurable to do many things based on both the source and a regexp of the contents of the log message, including sending email (and even that can be done externally, so if you want to use Python+SMTP, feel free to configure your logging that way). The email generation can be based on a regexp, so it can limit the messages it sends based on the regexp. Alternatively, the mail program invoked by the logger can do its own filtering and history maintenance, or you could have a cron job that did something like emailing whenever the ebuild logfile was updated (obviously only for systems with cron installed :). Regarding using a PORT_LOGDIR: This is where the logger is useful. You don't want everything, just certain output (like ewarn/eeror). Just setup your logging to log to the directory/ies and file/s you'd like it to. The logger will automatically rotate log files based on many factors, including size and age. Log files will have appropriate persistence, and will be located in customary locations (unless you redirect them otherwise). [Yes, I have read comment #83] Regarding modifying portage rather than baselayout: While I tend to agree that the einfo/ewarn/eerror functions should probably have been part of the portage package because that's the only place those seem to be used, I don't think it's appropriate to make significant cross-package changes to add a small enhancement. The new generation of portage is being designed even now, so I'm assuming that the designers are watching portage bugs and will take these issues into account where appropriate for the new portage; minimizing churn in the current generation will actually help those folks. Most loggers can invoke an arbitrary external command, so you get very significant amounts of flexibility based on the filters applied by the logger. See my wheel/SUV comment above, and apply the maxim that one of Unix's strengths is the ability to utilize many different small utilities in concert rather than building huge multifunction applications (epitomized by MSWord). Yes, I'm making the argument/assumption that logging/emailing/RSSing/paging/text-messaging/whatevering during system installation/bootstrap is of low value. I know this can be argued, but it should be juxtaposed against the effort required to develop a custom portage-internal solution to all the problems that are already handled by system utilities designed for just such purposes.
Okay.. forget about mail/syslog/etc for the time being. Just create a patch that has the following 2 problems solved and add that stuff later. 1. Lines are never intermingled even if there are 100 concurrent emerges. 2. Lines from pkg_setup to post_install remain in one block.
Created an attachment (id=36784) [edit] patch to ebuild.sh to collect einfo/eerror/ewarn messages This patch to the cvs version of ebuild.sh will collect einfo/eerror/ewarn messages in ${T}/messages so that they can be emailed/logged/handled another way later.
*** Bug 60706 has been marked as a duplicate of this bug. ***
*** Bug 60912 has been marked as a duplicate of this bug. ***
Lovely :) When do you think we'll have this working?
A modification similar to William's from above I intend to slip in after .51 is out the door. Right now, under a bit of a moratorium on new features for 2.0.51* . I intend to just nail down info/warn output, summarizing at the end... the extra stuff people are after is another thing.
How about this patch to ebuild.sh: http://dev.gentoo.org/~eldad/ebuild.sh-enotice.patch Other than overriding einfo/ewarn/eerror, it also goes a step further and put the notice file in a user-defined directory (PORT_ENOTICE_DIR env in /etc/make.conf)
I changed the patch abit, and also written a nice (python) tool to read/delete the notices: http://dev.gentoo.org/~eldad/enotice
Ok, I've tried your patch eldad but I can't get it to work. Here's what I did: # vi /etc/make.conf (set PORT_ENOTICE_DIR to /var/log/portage-enotices) # mkdir /var/log/portage-enotices # cd /usr/sbin/ # ls -l ebuild.sh (note that it's a symlink) # cd /usr/lib/portage/bin # wget "http://dev.gentoo.org/~eldad/ebuild.sh-enotice.patch" # patch < ebuild.sh-enotice.patch (patch succeeds) # cd /usr/local/sbin # wget "http://dev.gentoo.org/~eldad/enotice" # chmod u+x enotice # emerge gentoolkit (there's an einfo at the bottom) # enotice No notices found. # ls -a /var/log/portage-enotices/ ./ ../ what am I doing wrong?
Probably a permission problem on PORT_ENOTICE_DIR. I've changed the patch abit to create and se
