Bug 394502 switched to libxul. As a result there's lots of shared/static build addition and removals for each file to cleanup to get only what is needed for libxul builds.
Severity: normal → major
blocking-seamonkey2.1: --- → ?
From all I'm seeing, we're not missing any files we need to package, so this is minor. That said, we can remove all support for packaging anything else but the now-default "fatlibxul" builds. Also, on removed-files, we can clean up enough to only support coming from any build that was actually released for 2.x including milestones as well as nightlies from the last week or so.
Severity: major → minor
blocking-seamonkey2.1: ? → ---
This patch adapts packaging for the new world where we only support libxul builds there. This is basically nothing else than removal of any shared libs from packaging, adding the new startup cache that now builds since we switched, and removing any support for other build variants from removed-files (i.e. make it remove anything from possibly previously shipped shared builds). I *think* there might be further cleanup possible for removed-files but I don't want to dig into what files exactly we shipped in what release - at least, not at this moment.
Oh, what I meant to say wrt review, I'll take whoever of you will get to it first.
Target Milestone: --- → seamonkey2.1b1
Comment on attachment 477631 [details] [diff] [review] adapt packaging for libxul world I didn't line-by-line review this, but it looks good. I'll double-check package-compare _after_ this lands.
I just built on Win7 (current MozillaBuild + pymake) with --disable-libxul --disable-ipc (and without the patch from this bug) after pymake failed without those (no time to investigate yet), and now have a build that compiled but doesn't start anymore due to a missing xpcom_core.dll (I'm building the installer ZIP and extracting it, so am deliberately subject to packaging issues). Is this bug about removing the ability to build with the above options, and was it ever supposed to work? I got the impression it should after reading Standard8's posting to m.d.a.seamonkey ("Landing libxul on comm-central").
Landed as http://hg.mozilla.org/comm-central/rev/3bffdd67505f Jens, try clobbering and not using any of those two options. And yes, shared builds with that config are not much tested right now.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Actually, Jens's statement reminded me we also should port that little block that makes it clear that we only support libxul for packaging now.
Attachment #477757 - Flags: review?(bugspam.Callek)
Attachment #477757 - Flags: review?(bugspam.Callek) → review+
Comment on attachment 477757 [details] [diff] [review] error out on packaging if we're not libxul Landed that followup as http://hg.mozilla.org/comm-central/rev/2caef1a38423
(In reply to comment #5) > I just built on Win7 (current MozillaBuild + pymake) with --disable-libxul > --disable-ipc (and without the patch from this bug) after pymake failed without > those (no time to investigate yet) Filed bug 600023 for that (sorry for the noise).
You need to log in before you can comment on or make changes to this bug.