Thread: contrib like modules in Red Hat problem, Re: A "bug" report for orafce

Hello

is any chance to share standard Makefile and RH Makefile? I am sorry.
I don't understand to Makefile absolutely. It's look so global
Makefile need some changes.

Any help is welcome.

Regards
Pavel Stehule


On 21/01/2008, Devrim GÜNDÜZ <devrim@commandprompt.com> wrote:
> Hi Pavel,
>
> Orafce is about to be approved for Fedora, and I need help for one of
> the review items. Per:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=251805#c1
>
> There is a comment:
>
> " You should improve Makefile to enable to build with non-privilleged
> user See the attachment. "make install" tries to make a directory of
> "/usr/share/pgsql/contrib", and %buildroot is not used.
> I could not build your package because of this problem. "
>
> The log is here:
>
> https://bugzilla.redhat.com/attachment.cgi?id=172420
>
> Could you please look at the reason why? I fixed the other issues in the
> spec file.
>
> Thanks a lot.
>
> Regards,
>
> --
> Devrim GÜNDÜZ , RHCE
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
> Managed Services, Shared and Dedicated Hosting
> Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
>
>

"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> On 21/01/2008, Devrim GÜNDÜZ <devrim@commandprompt.com> wrote:
>> Orafce is about to be approved for Fedora, and I need help for one of
>> the review items. Per:
>> https://bugzilla.redhat.com/show_bug.cgi?id=251805#c1

AFAICT, there's nothing wrong with the Makefile.  The problem is with
the specfile, which apparently is calling plain "make install".
It should read

%install
rm -rf $RPM_BUILD_ROOT

make DESTDIR=$RPM_BUILD_ROOT install

Devrim: you should be testing specfiles by building as non-root;
you would have caught this yourself.
        regards, tom lane

Tom Lane wrote:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>   
>> On 21/01/2008, Devrim GÃœNDÃœZ <devrim@commandprompt.com> wrote:
>>     
>>> Orafce is about to be approved for Fedora, and I need help for one of
>>> the review items. Per:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=251805#c1
>>>       
>
> AFAICT, there's nothing wrong with the Makefile.  The problem is with
> the specfile, which apparently is calling plain "make install".
> It should read
>
> %install
> rm -rf $RPM_BUILD_ROOT
>
> make DESTDIR=$RPM_BUILD_ROOT install
>
> Devrim: you should be testing specfiles by building as non-root;
> you would have caught this yourself.
>
>
>   

Shouldn't one always build RPMs as non-root?

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Devrim: you should be testing specfiles by building as non-root;
>> you would have caught this yourself.

> Shouldn't one always build RPMs as non-root?

That'd be my advice --- the other way is archaic, not to mention a
bit of a security risk.
        regards, tom lane

Hi,

On Mon, 2008-01-21 at 11:17 -0500, Tom Lane wrote:
> Devrim: you should be testing specfiles by building as non-root;
> you would have caught this yourself.

Even though it means a lot of work in my current setup, this is what
will happen eventually, especially after the Makefile.regress problem
you found. I should have seen it before.

Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Hi,

On Mon, 2008-01-21 at 11:26 -0500, Andrew Dunstan wrote:
> Shouldn't one always build RPMs as non-root?

Probably, if the packager is not lazy ;)

Regards,

--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

> Tom Lane wrote:
>
>> %install
>> rm -rf $RPM_BUILD_ROOT
>>
>> make DESTDIR=$RPM_BUILD_ROOT install

I hope nobody tries building in a directory with a space in it...

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!

Devrim GÜNDÜZ <devrim@CommandPrompt.com> writes:
> On Mon, 2008-01-21 at 11:26 -0500, Andrew Dunstan wrote:
>> Shouldn't one always build RPMs as non-root?

> Probably, if the packager is not lazy ;)

It's really not hard, it just takes a couple of minutes of one-time
setup.  Make a file ~/.rpmmacros containing (in my case)

%_topdir /home/tgl/rpmwork

then create the directory ~/rpmwork and under it the five directories
BUILD/    RPMS/     SOURCES/  SPECS/    SRPMS/

Now you put your SRPMS in ~/rpmwork/SRPMS and run rpmbuild there,
same as you would do in /usr/src/redhat, you're just not root.
Much safer.

(Obviously, you can put your rpmwork directory wherever you want and
call it whatever you want, adjusting the _topdir macro to match.
What I show above is the customary thing for Red Hat engineers,
though.)
        regards, tom lane

Hi,

On Mon, 2008-01-21 at 12:31 -0500, Tom Lane wrote:
> It's really not hard, it just takes a couple of minutes of one-time
> setup.
<snip>

I *know* how to build the RPMs as non root :-) -- we are talking about
~60 servers to be setup like this . That's why it will take a bit time.

I'll try to this asap.

Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Devrim GÜNDÜZ <devrim@CommandPrompt.com> writes:
> I *know* how to build the RPMs as non root :-) -- we are talking about
> ~60 servers to be setup like this . That's why it will take a bit time.

You mean the RPM buildfarm?  I would've thought that was already set up
as non-root --- or are you skipping the regression-test step?
        regards, tom lane

Hi,

On Mon, 2008-01-21 at 13:08 -0500, Tom Lane wrote:
> > I *know* how to build the RPMs as non root :-) -- we are talking
> > about ~60 servers to be setup like this . That's why it will take a
> > bit time.
>
> You mean the RPM buildfarm?

Yes.

> I would've thought that was already set up as non-root

No:(

> --- or are you skipping the regression-test step?

Yes, that's why I could not find out the regression problem before you.

Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Devrim GÜNDÜZ escribió:

> On Mon, 2008-01-21 at 12:31 -0500, Tom Lane wrote:
> > It's really not hard, it just takes a couple of minutes of one-time
> > setup. 
> <snip>
> 
> I *know* how to build the RPMs as non root :-) -- we are talking about
> ~60 servers to be setup like this . That's why it will take a bit time.

You don't need to set up all the machines this way, only the one where
you actually write and test the SPEC file.

Anyway, a single file listing the 60 servers and a for loop in shell
should be plenty to setup the environment Tom shows ...

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@CommandPrompt.com> writes:
> You don't need to set up all the machines this way, only the one where
> you actually write and test the SPEC file.

Well, actually, I'm fairly unhappy that Devrim's skipping the "make
check" step while building those RPMs (which he must do because it
won't work as root).  So there seems to me to be plenty of argument
for fixing the build farm too.

But yeah, the immediate point is development of a new package's
specfile, which you'd hardly do on a server farm.
        regards, tom lane

Am Montag, 21. Januar 2008 schrieb Tom Lane:
> %_topdir /home/tgl/rpmwork
>
> then create the directory ~/rpmwork and under it the five directories
> BUILD/    RPMS/     SOURCES/  SPECS/    SRPMS/

Some distributions set up their standard build areas under /usr/src to be 
world writeable (sticky bit and all).  You might find that that also works 
for you.  It might be easier to set up for the build farm.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/