Jump to content
  • 0

Accessing dead ebuilds from Funtoo Git


Question

13 answers to this question

Recommended Posts

  • 0

Yes, I already use the "show dead files" function on s.g.o., and I understand NOT to do it in the /usr/portage directory.

 

I already have a local overlay.  Occasionally I will have the need to keep a "dead" ebuild in my local overlay tree.  I usually can get all the files from s.g.o. but not if it is a forked funtoo ebuild with it's own patch files.

 

How would one find, list and obtain/download funtoo's "dead files"?

Link to post
Share on other sites
  • 0

mail-mta/postfix-2.8.17.  I had some issues that I didn't have time to troubleshoot and I wanted to keep this version in my local overlay.  No need now.  I finally spent the time to correct my problems and get 2.11.3-r2 working.  One big problem was that I had a line beginning with whitespace in main.cf that was ignored in earlier versions of postfix, but 2.9, 2.10 and 2.11 parsed that line causing the fatal error and throttling.  Took me a while to find the culprit.

 

It would be nice if one could gather the files necessary from a dead funtoo custom ebuild and add them to one's local overlay.

Edited by overkill
Link to post
Share on other sites
  • 0

Here's the first error after updating:

Jan 10 14:43:06 newton postfix/smtpd[9628]: fatal: bad numerical configuration: smtpd_recipient_limit = 128  /usr/libexec/postfix/smtpd 9628 & sleep 5
Jan 10 14:43:07 newton postfix/master[9619]: warning: process /usr/libexec/postfix/smtpd pid 9628 exit status 1
Jan 10 14:43:07 newton postfix/master[9619]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling

which was triggered by this portion of main.cf:

...
smtpd_banner = $mydomain ESTMP
smtpd_recipient_limit = 128
#smtpd_timeout = 10
#soft_bounce = no

#debug_peer_level = 2
#debug_peer_list = 10.0.0.10 127.0.0.1
#debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb
  $daemon_directory/$process_name $process_id & sleep 5
...

The <whitespace> $daemon_directory/.... was ignored as the continuation of the line above it in 2.8.17, but later versions parsed it as a continuation of the uncommented lines above it.  At first I didn't understand the log's output.  Using the command `postconf smtpd_recipient_limit` showed that the $daemon_directory line was tacked on the end of the previously uncommently line, creating a bad key/value pair.

newton ~ # postconf smtpd_recipient_limit
smtpd_recipient_limit = 128 $daemon_directory/$process_name $process_id & sleep 5

Placing a # before the <whitespace> $daemon_directory line corrects the issue.

 

Weird, since this main.cf file has been like that for a couple of years and never had that problem.

Link to post
Share on other sites
  • 0

Yes.  now it looks like this...

...
smtpd_banner = $mydomain ESTMP
smtpd_recipient_limit = 128
smtpd_timeout = 10
soft_bounce = no

#debug_peer_level = 2
#debug_peer_list = 10.0.0.10 127.0.0.1
#debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb
#  $daemon_directory/$process_name $process_id & sleep 5
...

...and it works as it should

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...