Bug 58116 – The -p argument does not work with ebtables-2.0.6.ebuild

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Andrej Kacian (RETIRED) 2004-07-23 13:47:37 UTC]

This happens when trying to use ebtables installed from ebtables-2.0.6.ebuild:

# ebtables -A FORWARD -p IPv4 -j ACCEPT
Problem with the specified protocol.

Problem seems to be the ETHERTYPESPATH variable passed by einstall in src_install() function:

        einstall MANDIR=${D}/usr/share/man ETHERTYPESPATH=${D}/etc/ BINPATH=${D}/sbin/ || die

I have modified the existing ebuild (patch attached) so the -p argument is working.

[Comment 1 Andrej Kacian (RETIRED) 2004-07-23 13:48:23 UTC]

Created attachment 36031 [details, diff]
patch against ebtables-2.0.6.ebuild

[Comment 2 Andrej Kacian (RETIRED) 2004-07-23 13:51:28 UTC]

Whoops, this patch seems to break sandbox, disregard it, I'm working on a solution...

[Comment 3 Andrej Kacian (RETIRED) 2004-07-23 13:56:18 UTC]

Hm, I'm at a loss on this one - if I don't specify ETHERTYPESPATH to point to inside sandbox, emerge barfs on me with sandbox access violation, as ethertypes file gets installed into live /etc directory.

However, if I specify this variable for einstall, the original error happens.

Can anyone suggest a solution other than modifying Makefile not to copy ethertypes file, so we can copy it manually?

[Comment 4 Andrej Kacian (RETIRED) 2004-07-23 14:06:47 UTC]

Created attachment 36032 [details, diff]
working patch against ebtables-2.0.6.ebuild

Ok, this one works. The trick was to issue make command before make install
(einstall), because Makefile sets path to ethertypes file via gcc's -D
directive, so the sandbox path gets hardcoded into the compiled binary.

With this patch, we compile ebtables with default path hardcoded
(/etc/ethertypes), and ETHERTYPESPATH variable to einstall only affects where
to copy the actual ethertypes file. Neat.

[Comment 5 solar (RETIRED) 2004-07-24 05:11:57 UTC]

Andrej,
Good catch.
I've updated the ebtables ebuild in CVS so please test that ebtables will work as expected.

[Comment 6 Andrej Kacian (RETIRED) 2004-07-24 09:00:56 UTC]

Well, if you used exactly my patch, it will work. I am already using that -r1 ebuild from my local overlay and it works nicely. Will test it as soon as the ebuild hits my mirror and reopen this bug if something's not right.

[Comment 7 Andrej Kacian (RETIRED) 2004-07-28 11:02:56 UTC]

Looks like you either forgot to bump the ebuild version to -r1, or did not bump deliberately. May I ask why?

[Comment 8 solar (RETIRED) 2004-07-28 11:34:50 UTC]

ebuilds should only be bumped when they add new functionlaity or when it's a version change. This is fixes existing functionality for a ~arch pkg.

[Comment 9 Andrej Kacian (RETIRED) 2004-08-06 05:49:57 UTC]

I'm using this ebtables ebuild on a production machine and it works alright. Closing this bug as FIXED.