Closed Bug 548788 Opened 14 years ago Closed 12 years ago

[Shredder] Trunk packaging shouting about a missing file: "config/printconfigsetting.py': [Errno 2] No such file or directory"

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(status1.9.2 .4-fixed, status1.9.1 .10-fixed)

RESOLVED FIXED
mozilla1.9.3a3
Tracking Status
status1.9.2 --- .4-fixed
status1.9.1 --- .10-fixed

People

(Reporter: fredbezies, Assigned: sgautherie)

References

Details

(Keywords: regression, Whiteboard: [ToDo: (answer) comment 8])

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a2pre) Gecko/20100226 Firefox/3.7a2pre
Build Identifier: 

Even if I cannot run anymore Shredder (it segfaults on start since two days or so), I noticed a packaging bug on trunk.

After a successful build, when in objdir-tb I enter make package, in the remove part, I got this :

Removing unpackaged files...
/usr/bin/python: can't open file '/home/fred/logs/mail/src/config/printconfigsetting.py': [Errno 2] No such file or directory


Reproducible: Always

Steps to Reproduce:
1.See details
2.
3.
Actual Results:  
Shouting about a missing python file.

Expected Results:  
Nothing. Just plain packaging process.

here is my .mozconfig :

#
# See http://www.mozilla.org/build/ for build instructions.
#

export AUTOCONF=autoconf-2.13

ac_add_options --enable-application=mail
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-tb
mk_add_options MOZ_MAKE_FLAGS="-j4"

# Options for ‘configure’ (same as command-line options).
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --enable-static
ac_add_options --disable-shared
ac_add_options --enable-calendar
Hardware: x86 → x86_64
(In reply to comment #0)
> Even if I cannot run anymore Shredder (it segfaults on start since two days or
> so), I noticed a packaging bug on trunk.

That's bug 546913.
 
> After a successful build, when in objdir-tb I enter make package, in the remove
> part, I got this :
> 
> Removing unpackaged files...
> /usr/bin/python: can't open file
> '/home/fred/logs/mail/src/config/printconfigsetting.py': [Errno 2] No such file
> or directory

Ok, I think I see what's causing this.
Assignee: nobody → bugzilla
Blocks: 474610
Product: Thunderbird → Core
QA Contact: build-config → build-config
Version: unspecified → Trunk
(In reply to comment #1)
> (In reply to comment #0)
> > Even if I cannot run anymore Shredder (it segfaults on start since two days or
> > so), I noticed a packaging bug on trunk.
> 
> That's bug 546913.

Again ? I thought it was fixed. My own shredder build was made on 24 february.

> 
> > After a successful build, when in objdir-tb I enter make package, in the remove
> > part, I got this :
> > 
> > Removing unpackaged files...
> > /usr/bin/python: can't open file
> > '/home/fred/logs/mail/src/config/printconfigsetting.py': [Errno 2] No such file
> > or directory
> 
> Ok, I think I see what's causing this.

Thanks.
Summary: [Shredder] Trunk packaging shouting about a missing file. → [Shredder] Trunk packaging shouting about a missing file: "config/printconfigsetting.py': [Errno 2] No such file or directory"
I probably should have used $(MOZILLA_DIR) or something, shouldn't I?
(In reply to comment #3)
> I probably should have used $(MOZILLA_DIR) or something, shouldn't I?

Ah, yeah!
And, while there, there's a |$(topsrcdir)/build/package/wince/make_wince_cab.py| in packager.mk too...
http://mxr.mozilla.org/comm-central/search?string=topsrcdir&case=1&find=%2Finstaller%2F.*%5C.mk
Flags: in-testsuite-
Keywords: regression
OS: Linux → All
Hardware: x86_64 → All
(In reply to comment #4)
> |$(topsrcdir)/build/package/wince/make_wince_cab.py| in packager.mk too...

Added by
http://hg.mozilla.org/mozilla-central/rev/307da4daceb8
Bug 511662, add packaging targets for creating CAB files (for WinCE)
Blocks: 511662
Feel free to take, I've been diverted onto other things for a while.
Assignee: bugzilla → nobody
Assignee: nobody → sgautherie.bz
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.9.3a2
Attachment #429146 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 429146 [details] [diff] [review]
(Av1) 2+1 s/topsrcdir/MOZILLA_DIR/
[Checkin: Comment 9 & 20 & 24]


http://hg.mozilla.org/mozilla-central/rev/3bc1d24c6277


"approval1.9.2.2=?":
Zero risk, build config only.
packager.mk part already applies;
package-name.mk part will be needed if/when bug 474610 lands on m-1.9.2.
Attachment #429146 - Attachment description: (Av1) 2+1 s/topsrcdir/MOZILLA_DIR/ → (Av1) 2+1 s/topsrcdir/MOZILLA_DIR/ [Checkin: Comment 9]
Attachment #429146 - Flags: approval1.9.2.2?
Whiteboard: [ToDo: (answer) comment 8]
Target Milestone: mozilla1.9.3a2 → mozilla1.9.3a3
Bv1-CC, with a comment fix.
Attachment #430008 - Attachment is obsolete: true
Attachment #430012 - Flags: review?(bugzilla)
Attachment #430008 - Flags: review?(bugzilla)
*Ease diff with comm-central.
*Later, I'll check if we could merge the 2-3 copies...
Attachment #430013 - Flags: review?(ted.mielczarek)
Comment on attachment 430013 [details] [diff] [review]
(Cv1) rules.mk: use $(MOZILLA_DIR) instead of $(topsrcdir) in tests commands, Indentation nits

Please stop randomly reindenting stuff that you don't have to. It doesn't help things.
Attachment #430013 - Flags: review?(ted.mielczarek) → review-
Attachment #429146 - Flags: approval1.9.2.2? → approval1.9.2.3?
Comment on attachment 430012 [details] [diff] [review]
(Bv1a-CC) Use $(MOZILLA_DIR) instead of $(topsrcdir)/mozilla where possible
[Checkin: Comment 15]

There's probably a little bit of bitrot in this, but I'm sure you can fix that ;-)
Attachment #430012 - Flags: review?(bugzilla) → review+
Comment on attachment 430012 [details] [diff] [review]
(Bv1a-CC) Use $(MOZILLA_DIR) instead of $(topsrcdir)/mozilla where possible
[Checkin: Comment 15]


http://hg.mozilla.org/comm-central/rev/fa976251fb9d
Attachment #430012 - Attachment description: (Bv1a-CC) Use $(MOZILLA_DIR) instead of $(topsrcdir)/mozilla where possible → (Bv1a-CC) Use $(MOZILLA_DIR) instead of $(topsrcdir)/mozilla where possible [Checkin: Comment 15]
(In reply to comment #8)
> Mark, am I right that c-c should be able to use MOZILLA_DIR (almost)
> everywhere?

MOZILLA_SRCDIR is c-c specific.
Could we s/MOZILLA_SRCDIR/MOZILLA_DIR/g (with a few nits)?
(In reply to comment #16)
> (In reply to comment #8)
> > Mark, am I right that c-c should be able to use MOZILLA_DIR (almost)
> > everywhere?
> 
> MOZILLA_SRCDIR is c-c specific.
> Could we s/MOZILLA_SRCDIR/MOZILLA_DIR/g (with a few nits)?

Not really.  MOZILLA_SRCDIR is defined from configure and put into autoconf.mk for us. rules.mk is defined at the end of most makefiles, and should certainly be after many var definitions.

MOZILLA_DIR is of course only defined in rules.mk (I'm not opposed to moving it to config.mk for us; but would like m-c to match). if its put into config.mk then I'm ok with this switch, but until then we can only use it in places we should _expect_ rules.mk to already have been defined (such as inside rules.mk itself for places where MOZILLA_SRCDIR is used there for us)
(In reply to comment #17)
> ... rules.mk is defined at the end ...

s/defined/included/
Comment on attachment 429146 [details] [diff] [review]
(Av1) 2+1 s/topsrcdir/MOZILLA_DIR/
[Checkin: Comment 9 & 20 & 24]

a=beltzner for 1.9.2.4
Attachment #429146 - Flags: approval1.9.2.4? → approval1.9.2.4+
Comment on attachment 429146 [details] [diff] [review]
(Av1) 2+1 s/topsrcdir/MOZILLA_DIR/
[Checkin: Comment 9 & 20 & 24]


http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a138c2d30a58
Attachment #429146 - Attachment description: (Av1) 2+1 s/topsrcdir/MOZILLA_DIR/ [Checkin: Comment 9] → (Av1) 2+1 s/topsrcdir/MOZILLA_DIR/ [Checkin: Comment 9 & 20]
Attachment #429146 - Flags: approval1.9.1.10?
Does that patch apply cleanly for 1.9.1.10? We didn't realize that this affected that branch - had you just forgotten to ask for that approval as well?
(In reply to comment #21)

> Does that patch apply cleanly for 1.9.1.10? We didn't realize that this

http://mxr.mozilla.org/mozilla1.9.1/search?string=printconfigsetting.py&case=1&find=%2Fmozapps%2Finstaller%2F
The package-name.mk part should apply, the packager.mk part doesn't exist (= irrelevant) on m-1.9.1.

> affected that branch - had you just forgotten to ask for that approval as well?

Bug 474610 went into m-1.9.1. (though noone has complained yet :-|)
No, just asking the second after the first was approved.
Comment on attachment 429146 [details] [diff] [review]
(Av1) 2+1 s/topsrcdir/MOZILLA_DIR/
[Checkin: Comment 9 & 20 & 24]

a19110=beltzner
Attachment #429146 - Flags: approval1.9.1.10? → approval1.9.1.10+
Comment on attachment 429146 [details] [diff] [review]
(Av1) 2+1 s/topsrcdir/MOZILLA_DIR/
[Checkin: Comment 9 & 20 & 24]


http://hg.mozilla.org/releases/mozilla-1.9.1/rev/905d6efd3da8
Attachment #429146 - Attachment description: (Av1) 2+1 s/topsrcdir/MOZILLA_DIR/ [Checkin: Comment 9 & 20] → (Av1) 2+1 s/topsrcdir/MOZILLA_DIR/ [Checkin: Comment 9 & 20 & 24]
Long fixed. Closing it ?
Yes, I think this can be closed. In response to comment 8, I don't know the answer - "probably", but any changes should, of course, be in follow-up bugs, as this was fixed ages ago.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: