Jump to content
funtoo forums
  • 0
overkill

Accessing dead ebuilds from Funtoo Git

Question

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?

Share this post


Link to post
Share on other sites

13 answers to this question

Recommended Posts

  • 0

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

Share this post


Link to post
Share on other sites
  • 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"?

Share this post


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

Share this post


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.

Share this post


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

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


Link to post
Share on other sites
  • 0

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.

Share this post


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

×