(In reply to comment #0)
> It could be done automatically, since we drop the cleaning from our .spec
> files.

Where ? in rpm ? is the BS ? yourri ? svn submit ?

Keywords: (none) => NEEDINFO

I build it locally using bm. If the output files change then the old aren't erased.

I just checked out get-skype which has no %prep or %build.
Using bm -al it builds, and after the build, BUILDROOT is empty.

There is nothing in the spec that cleans it "manually".

Maybe I misunderstand your question ;)

CC: (none) => zen25000

Note the last few lines of output:-

Wrote: /home/baz/get-skype/SRPMS/get-skype-2.2.0.35-17.mga2.src.rpm
Wrote: /home/baz/get-skype/RPMS/noarch/get-skype-2.2.0.35-17.mga2.noarch.rpm
Executing(%clean): /bin/sh -e /home/baz/get-skype/BUILDROOT/rpm-tmp.x99g4L
+ umask 022
+ cd /home/baz/get-skype/BUILD
+ /bin/rm -rf /home/baz/get-skype/BUILDROOT/get-skype-2.2.0.35-17.mga2.x86_64
+ exit 0
succeeded!

As I don't really understand, I added the committer of bm, maintainer of rpm and sysadmin, feel free to remove you.

CC: (none) => dmorganec, mageia

(In reply to comment #5)
> As I don't really understand, I added the committer of bm, maintainer of rpm
> and sysadmin, feel free to remove you.

Sorry Manuel - my point was that I don't see a problem. Unless I missed the point ;)

Created attachment 1155 [details]
example

I'm attaching a very early SRC.RPM of a package (for private usage - not for our repo).

If I remove the cleaning part in %install, and change location of the files to be installed - then I got error with unpackages %files - the old files remain in the old place.

Created attachment 1156 [details]
cleaned spec

I cannot reproduce your issue using your srpm.
I tested (in fully up to date Cauldron) as follows:-
 
I removed the rm -fR %{buildroot} line.
I built it using bm -bl
I then replaced all instances of %{_bindir} with %{_sbindir}
I built it again with no errors.

I have attached a slightly modified spec.

There is no need to include unused sections so I have removed them.
I have also removed the rm -fR %{buildroot}

I again tested as above with this and again I cannot reproduce your issue.

In all cases BUILDROOT is empty after each build.

I will test it again.

Ok, it seems OK now I think, I don't know how I did it and had several problems with the ghost files.

If I will reproduce again, I will reopen this.

Thanks!

Resolution: (none) => INVALID
Status: NEW => RESOLVED

Created attachment 1188 [details]
two builds log

I am working with ScrotWM.
I have it reproduced today and faced it today again.. twice..

1)
I was preparing the %make and %install sections (well this involves patching in %prep :) ) and I had problem: why the files are duplicated in /usr/local! After searching everywhere I had an idea about this bug... so I have cleaned finally my files in BUILD and BUILDROOT.. and bingo! :)

2)
The same problem this time with adjusting a .desktop file, it had added (with a mistake) into /usr/share - but not into %files section => error, build failed.
So I have changed it into the correct place and added the entry into %files with the right path. What happend? Build failed, and I am sure where is the bug!

I attach the last with the 2nd scenario today.

Attachment 1156 is obsolete: 0 => 1
Attachment 1155 is obsolete: 0 => 1

I have detected the bug, so reopened.

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

Ah sorry, the file wasn't listed in %file section at the end of the story. But it doesn't change the story - I have just added it and made "bm -l" for sure - same result.

Please use 
LC_ALL=C bm -l 
when preparing logs for attachment, so the errors are in English ;) 

I see your issue.
I agree that %{buildroot} is NOT cleaned automatically at the start of the %install section.
%{buildroot} is cleaned after a successful build, but not after a failed build, so it would be prudent to use:-

%install
rm -rf %{buildroot}

at all times - especially during development when build failures are likely.

I based my comment above in #8 about the need for rm -rf %{buildroot} on these guidelines:-

http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag

However it seems that currently this is incorrect.
Sorry for any confusion.

I'm not preparing logs with virtual bugs but warking with real packages! So therefor I don't see a point of remaking everything, reverting my changes in .spec just for some LC_ALL values.

Well since we are removing entries "rm -rf %{buildroot}" from SPEC as unneeded ones -> look at .spec changes like http://svnweb.mageia.org/packages/cauldron/sjeng-free/current/SPECS/sjeng-free.spec?r1=177162&r2=177161&pathrev=177162 then this is actually a bug and not my mistake.

(In reply to comment #15)
> I'm not preparing logs with virtual bugs but warking with real packages! So
> therefor I don't see a point of remaking everything, reverting my changes in
> .spec just for some LC_ALL values.

For a bug report, this would still be more meaningful.

> Well since we are removing entries "rm -rf %{buildroot}" from SPEC as unneeded
> ones -> look at .spec changes like
> http://svnweb.mageia.org/packages/cauldron/sjeng-free/current/SPECS/sjeng-free.spec?r1=177162&r2=177161&pathrev=177162
> then this is actually a bug and not my mistake.

I agree -  I think that this bug should be kept open.

tracked at https://bugs.launchpad.net/rpm/+bug/913239

CC: (none) => n3npq

Changing:
 
Product to Infrastructure

Component to Buildsystem

Assignee: bugsquad => sysadmin-bugs
Keywords: NEEDINFO => (none)
CC: (none) => marja11
Component: RPM Packages => BuildSystem
Version: 1 => unspecified
Product: Mageia => Infrastructure

reverting changes, I misunderstood the bug was on the server side, but it isn't

Assignee: sysadmin-bugs => bugsquad
Component: BuildSystem => RPM Packages
Version: unspecified => 1
Product: Infrastructure => Mageia

the bug is in rpm-build
assiging to maintainer

Assignee: bugsquad => dmorganec
Source RPM: (none) => rpm-4.8.1 src.rpm

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad

Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no 
longer maintained, which means that it will not receive any further security or 
bug fix updates. As a result we are closing this bug. 

If you can reproduce this bug against a currently maintained version of Mageia 
please feel free to click on "Version" change it against that version of Mageia and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
Mageia Bugsquad

Resolution: (none) => WONTFIX
Status: REOPENED => RESOLVED