[gentoo-user] Introduce Manual manipulation during an emerge

[gentoo-user] Introduce Manual manipulation during an emerge

[Harry Putnam]

I'm really sorry to keep beating on this portage stuff and I guess I
must be something of a dimwit since I find just about anything to do
with portage and emerge that is outside `emerge -flags whatever'
to be really hard to catch on to, even though (and shouldn't admit
this) I've been running gentoo for at least 5 yrs and probably more.

I read up on the parts I need at times when I run into trouble and get
much coaching and pointers here.   But then in a few mnths, with no
problems I've forgotten the vast bulk of whatever I picked up.  And I
mean even when I've made notes...

Anyway cutting to the chase:

I want to do some manual manipulation to a failing emerge of procmail.

    emerge -v procmail 
  (details here were posted elsewhere but involves somekind missnaming
  of getline in the ebuild)

It fails but has a simple enough fix. It needs to have a sed exchange
take place in the unpacked source.

Running  `sed -i -e 's/getline/get_line/g' src/*.c src/*.h'
In top level of the upacked source will allow it to compile fine.
So once all instances of getline are changed to get_line... it works.

Now how do I go about doing that right during the emerge?

For something like this it seems way overkill to have a separate
custom /usr/local/portage where I build my own.  Especially since I
find that whole process difficult and way overkill for this problem.

Further its something that will almost certainly be fixed soon and
won't be something I have to attend to again.

I'm pretty sure there is some way to introduce custom action during
emerge and remember doing something like that before to fix cvs so
root could commit.  It envolved either a ./configure or make flag that
portage didn't employ... somehow, with coaching here... I was able to
introduce a non-default flag.

Isn't there a simple way to introduce the sed run in procmail sources
during emerge?

Oh, and to fix cvs again too... with this new install I've started from
scratch after nursing one original install and upating over yrs. 

Re: [gentoo-user] Introduce Manual manipulation during an emerge

[Stroller]

On 12 Jun 2009, at 20:59, Harry Putnam wrote:
> ...
> For something like this it seems way overkill to have a separate
> custom /usr/local/portage where I build my own.  Especially since I
> find that whole process difficult and way overkill for this problem.
>
> Further its something that will almost certainly be fixed soon and
> won't be something I have to attend to again.

If you think that's the case then just mask the current version of  
procmail in /etc/portage/package.mask & remerge procmail. An older  
version without this bug will be installed & when an updated version  
is available portage will install it automagically.

I consider /usr/local/portage to be essential, because there's most  
always a package or three on my systems which I can't get through the  
regular tree, or which i wish to version bump myself. I don't consider  
this a hassle because I could create the updated ebuild with patch in  
a few minutes.

Because I most always check some reference resources when I do this, I  
can't quickly explain to you how to maintain this tree yourself. I  
think the time it would take you to learn this would be well-spent, as  
I'm sure you'll eventually need to use a /usr/local/portage package  
again in the future. Like I say, once you know how, it becomes easy.  
But if you consider it a hassle, just mask the buggy version of  
procmail & forget about the problem.

Stroller. 

[gentoo-user] Re: Introduce Manual manipulation during an emerge

[Harry Putnam]

Stroller <stroller@stellar.eclipse.co.uk> writes:

> But if you consider it a hassle, just mask the buggy version of
> procmail & forget about the problem.

Thanks... I thought of something like that but then noticed there's only
one version available in portage.

At that point I downloaded the previous version *21* tar ball and
attempted to build it just manually but hit the same getline problem.
(this was outside emerge)

The next version back behind 21 is quite old.
(I then built an installed version 22* by hand using the sed tools
... more below about that)

But can't I do something when the emerge breaks and tells me where the
sources are in /var/tmp... can't I go there and finish the build
somehow?  First the sed run, then ebuild (I know those ebuild
commands) and have the finished product installed with emerge?

And similarly with CVS.  I remember there being some way I could tell
emerge to let me set a ./configure flag by hand... then finish the
install (with emerge).  May have been some flag set right at the
emerge cmd like:

   # SOMEFLAG=something emerge -v cvs

Just for information... I have built procmail *22* by hand using the
afore mentioned sed command then symlinked /usr/local/bin/procmail to
/usr/bin/procmail, where sendmail expects it to be, and so am able to
run it fine and get mail working.  So not really a big problem... just
seems there'd be a fairly easy way to get this done with emerge short
of going the personal overlay route.

To me... the personal overlay just does not fall under `fairly easy'.

Re: [gentoo-user] Introduce Manual manipulation during an emerge

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On Fri, 12 Jun 2009 14:59:53 -0500
Harry Putnam <reader@newsguy.com> wrote:

> Isn't there a simple way to introduce the sed run in procmail sources
> during emerge?

  man 1 ebuild
  ebuild /usr/portage/mail-filter/procmail configure
  (do-some-sed-in-/var/tmp)
  ebuild /usr/portage/mail-filter/procmail merge

Ta da! ;)

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Introduce Manual manipulation during an emerge

[Harry Putnam]

Mike Kazantsev <mk.fraggod@gmail.com> writes:

> On Fri, 12 Jun 2009 14:59:53 -0500
> Harry Putnam <reader@newsguy.com> wrote:
>
>> Isn't there a simple way to introduce the sed run in procmail sources
>> during emerge?
>
>   man 1 ebuild
>   ebuild /usr/portage/mail-filter/procmail configure
>   (do-some-sed-in-/var/tmp)
>   ebuild /usr/portage/mail-filter/procmail merge
>
> Ta da! ;)

Yess indeed... Ta Da.. thank you... I new there was a simple way.

[gentoo-user] Re: Introduce Manual manipulation during an emerge

[Harry Putnam]

Mike Kazantsev <mk.fraggod@gmail.com> writes:

>   man 1 ebuild
>   ebuild /usr/portage/mail-filter/procmail configure
>   (do-some-sed-in-/var/tmp)
>   ebuild /usr/portage/mail-filter/procmail merge

Many thanks for the tips... and hugely usefull.

But:
Yikes I may have jumped the gun thinking I was good to go but at least
I now have the commands to get a little further... unfortunately the
build breaks for a different reason now.

 ebuild \
 /usr/portage/mail-filter/procmail/procmail-3.22-r10.ebuild configure

  cd to source:
 /var/tmp/portage/mail-filter/procmail-3.22-r10/work/procmail-3.22

  sed -i -e 's/getline/get_line/g' src/*.c src/*.h

(all good so far)

 ebuild \
 /usr/portage/mail-filter/procmail/procmail-3.22-r10.ebuild merge

 [...] tail of error below:

Whoeaaa!  There's something fishy going on here.
You have a look and see if you detect anything uncanny:
*******************************************************
i486-pc-linux-gnu-gcc -O2 -march=i486 -pipe -fno-inline-functions2 -march=i486 -pipe -fno-inline-functions _autotst.c -o _autotst -Wl,-O1
cc1: error: unrecognized command line option "-fno-inline-functions2"
::::
cc -O2 -march=i486 -pipe -fno-inline-functions2 -march=i486 -pipe -fno-inline-functions _autotst.c -o _autotst -Wl,-O1
cc1: error: unrecognized command line option "-fno-inline-functions2"
::::
gcc -O2 -march=i486 -pipe -fno-inline-functions2 -march=i486 -pipe -fno-inline-functions _autotst.c -o _autotst -Wl,-O1
cc1: error: unrecognized command line option "-fno-inline-functions2"
::::
*******************************************************
I suggest you take a look at the definition of CFLAGS* and CC
in the Makefile before you try make again.
make[1]: *** [init] Error 1
make[1]: Leaving directory `/var/tmp/portage/mail-filter/procmail-3.22-r10/work/procmail-3.22'
make: *** [src/Makefile] Error 2
 *
 * ERROR: mail-filter/procmail-3.22-r10 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 2531:  Called die
 * The specific snippet of code:
 *       emake CC="$(tc-getCC)" || die
 *  The die message:
 *   (no error message)

Re: [gentoo-user] Re: Introduce Manual manipulation during an emerge

[Arttu V.]

On Fri, 2009-06-12 at 16:22 -0500, Harry Putnam wrote:

> i486-pc-linux-gnu-gcc -O2 -march=i486 -pipe -fno-inline-functions2 -march=i486 -pipe -fno-inline-functions _autotst.c -o _autotst -Wl,-O1
> cc1: error: unrecognized command line option "-fno-inline-functions2"

What do put in your CFLAGS (e.g., in /etc/make.conf)? Typos there?

-- 
Arttu V.

[gentoo-user] Re: Introduce Manual manipulation during an emerge

[Harry Putnam]

"Arttu V." <arttuv69@gmail.com> writes:

> On Fri, 2009-06-12 at 16:22 -0500, Harry Putnam wrote:
>
>> i486-pc-linux-gnu-gcc -O2 -march=i486 -pipe -fno-inline-functions2
>> -march=i486 -pipe -fno-inline-functions _autotst.c -o _autotst
>> -Wl,-O1 cc1: error: unrecognized command line option
>> "-fno-inline-functions2"
>
> What do put in your CFLAGS (e.g., in /etc/make.conf)? Typos there?

Here is what is in there right now.. apparently from the stage3
pulled down during install a few days ago.

  CFLAGS="-O2 -march=i486 -pipe"
  CXXFLAGS="-O2 -march=i486 -pipe"
  CHOST="i486-pc-linux-gnu"

Looking at make.conf from an old backup I see:

  CFLAGS="-O2 -march=i686 -pipe"
  CHOST="i686-pc-linux-gnu"
  CXXFLAGS="${CFLAGS}"

So trying that now.

Haa  finished up smoothly with those flags changed.

Do you think I do something like `emerge -vuDN world' since everthing
was compiled up to now with the old flags shown above?

Re: [gentoo-user] Re: Introduce Manual manipulation during an emerge

[Arttu V.]

On Fri, 2009-06-12 at 18:39 -0500, Harry Putnam wrote:

> Here is what is in there right now.. apparently from the stage3
> pulled down during install a few days ago.
> 
>   CFLAGS="-O2 -march=i486 -pipe"
>   CXXFLAGS="-O2 -march=i486 -pipe"
>   CHOST="i486-pc-linux-gnu"

Is there a reason to use i486 stage3? I think an i686 one might have
been available and a better hit if your system is/was set up as an i686
before this? Well, not that it counts now, gotta go with what you have
unpacked.

> Looking at make.conf from an old backup I see:
> 
>   CFLAGS="-O2 -march=i686 -pipe"
>   CHOST="i686-pc-linux-gnu"
>   CXXFLAGS="${CFLAGS}"
> 
> So trying that now.
> 
> Haa  finished up smoothly with those flags changed.
> 
> Do you think I do something like `emerge -vuDN world' since everthing
> was compiled up to now with the old flags shown above?

The friendly gentoo devs have whole guide for this:

http://www.gentoo.org/doc/en/change-chost.xml

And, as you can see, it starts with the soothing words "Changing the
CHOST is a big issue that can seriously screw up your system" ...

I'd go through that guide first to get to a (hopefully) sane system, and
continue with other emergings only then.

-- 
Arttu V.

[gentoo-user] Re: Introduce Manual manipulation during an emerge

[Harry Putnam]

"Arttu V." <arttuv69@gmail.com> writes:

> Is there a reason to use i486 stage3? I think an i686 one might have
> been available and a better hit if your system is/was set up as an i686
> before this? Well, not that it counts now, gotta go with what you have
> unpacked.

Looking at those stages again... it is not apparent in any way that I
should have gotten something besides x86.

I see there is an i686.  But apparently I was to slow to figure out
that I needed it.

Thanks ... I'm working thru the CHOST doc now.