Accessing dead ebuilds from Funtoo Git

[overkill]

Is there a way to pull dead ebuilds (no longer in Funtoo tree) from funtoo git?

 

I can access dead gentoo ebuilds and files from sources.gentoo.org.

 

Is there any way to access and download dead funtoo-ported ebuilds from funtoo's git tree?

[Oleg Vinichenko]

yes, you can do that either from git or from sources.gentoo.org. on s.g.o there is option 'Show dead files' (dead) is shown after ebuild. With git you can do it in many ways but we not recommending doing it in portage dir as it getting overriden by next sync

[overkill]

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"?

[Oleg Vinichenko]

which ones and why? a bit in the dark here :)

[overkill]

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 January 13, 2015 by overkill

[Oleg Vinichenko]

please, give details on this parse error. postfix is a part of stage3 and under close attention.

[overkill]

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.

[Oleg Vinichenko]

did you change this lines in main.cf?

[overkill]

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

[Oleg Vinichenko]

i meant was it "bad" from start or you had changes while configuring postfix

[overkill]

It was my fault.  I enabled debugging at one point a year or two back, then failed to comment "ALL" the debug lines out when finished.  2.8.xx and earlier did not have any issue with it, but 2.9, 2.10 and 2.11 did.

[Oleg Vinichenko]

what we need to fix then?

[overkill]

I think you got sidetracked.  Look at the title of this post. :)

 

I just wanted to know how to pull dead funtoo-ported ebuilds from funtoo's tree.  If I had an issue that needed fixing, I'd post a bug report on b.f.o.

[Oleg Vinichenko]

ah, ok :)