Closed Bug 297960 Opened 20 years ago Closed 19 years ago

Make post-mozilla-rel.pl produce full update archives.

Categories

(Webtools Graveyard :: Tinderbox, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: darin.moz, Assigned: chase)

References

Details

Attachments

(2 files, 2 obsolete files)

Make post-mozilla-rel.pl produce full update archives.
Blocks: 290390
Attached patch package update.mar (obsolete) — Splinter Review
<darin> we need to add MOZ_CO_MODULE=mozilla/tools/update-packaging in order
+to use this
I think we also have to figure out a way to add that directory to
allmakefiles.sh so that a Makefile in tools/update-packaging gets created.  Or,
maybe we should just add tools/update-packaging to the default checkout.  It is
rather small.

bsmedberg, cls: what is the best way to handle this in your opinions?
I don't think we need it as part of the default checkout: adding a makefile to
allmakefiles.sh is fine, dependent on the configure flag.
OK, so we need a configure change in addition to adding MOZ_CO_MODULES to the
mozconfig.  That's fair.
Depends on: 297976
OK, now that my patch for bug 297976 is in, how do we go about getting the v1
patch (or some variant of it) in for the tinderboxen?
Darin, thanks for filing this bug and attaching your patch.  It's in my court now.
Comment on attachment 186519 [details] [diff] [review]
package update.mar

>+  if ($Settings::update_package) {
>+    TinderUtils::run_shell_command "make -C $objdir/tools/update-packaging full-update STAGE_DIR=$stagedir";
>+  }
>+

Probably mean $builddir here instead of $objdir.  I'm doing a trial run now.
I meant objdir because the Makefile is generated from Makefile.in.
(In reply to comment #9)
> I meant objdir because the Makefile is generated from Makefile.in.

Understood.  $objdir is passed into packit() with the variable name $builddir. 
Am I missing something?
Ah, ok... you're right.  When I searched around, I hit the code in packit_l10n
and confused myself.
I'm getting a build error on prometheus since in its
tools/update-packaging/Makefile srcdir is equal to '.', not the full path to
tools/update-packaging.  Here's the exact error:

make -C
/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/tools/update-packaging
full-update
STAGE_DIR=/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/dist/install/2005-06-20-12-trunk
make: Entering directory
`/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/tools/update-packaging'
mkdir -p
/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/dist/install/2005-06-20-12-trunk
(cd ../../dist/bin && MAR=/builds/tinderbox/Fx-Trunk/../../dist/host/bin/mar
./make_full_update.sh
/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/dist/install/2005-06-20-12-trunk/update.mar
.)
/bin/sh: line 1: ./make_full_update.sh: No such file or directory
make: *** [full-update] Error 127
make: Leaving directory
`/builds/tinderbox/Fx-Trunk/Linux_2.4.21-27.0.4.ELsmp_Depend/mozilla/tools/update-packaging'
I haven't had a chance to test this patch locally yet.
Comment on attachment 186865 [details] [diff] [review]
execute make_full_update.sh from Makefile without changing directory [checked in]

This patch works for me on prometheus.
Attachment #186865 - Attachment description: execute make_full_update.sh from Makefile without changing directory → execute make_full_update.sh from Makefile without changing directory [checked in]
Status: NEW → ASSIGNED
Darin, how can we derive the "platform" component of the update string from a
build system?  Is there some command I can run / file I can inspect to build
that?  From what I know I need to take the system OS software name and add the
XPCOM ABI name, but I'm not sure where you would like me to look for that in our
source tree.
In a makefile, the variables are OS_TARGET and TARGET_XPCOM_ABI, so you can either

do $(OS_TARGET)_$(TARGET_XPCOM_ABI)

or pull those vars "manually" from <objdir>/config/autoconf.mk
Attachment #186519 - Attachment is obsolete: true
Attachment #186519 - Attachment description: v1 patch → package update.mar
Attachment #186982 - Attachment is obsolete: true
Is this bug FIXED now?
Yes, the code in post-mozilla-rel.pl is not high enough quality that I'm 100%
happy with it as-is but it essentially works automatically now.  I'll resolve
fixed and come back to it later.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Component: Tinderbox Configuration → Tinderbox
Product: mozilla.org → Webtools
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: