[SM-Trunk] Missing files

[Hartmut Figge]

Gru�,

mein neues Build will nicht mit:

package-manifest ../../mozilla/dist ../../mozilla/dist/seamonkey \
--non-resource defaults/messenger/mailViews.dat
defaults/profile/localstore.rdf defaults/profile/panels.rdf
Error:
/home/hafi/moz-work/src/obj-x86_64-unknown-linux-gnu/suite/installer/package-manifest:263:
Missing file(s): bin/components/NavigatorPropertyHelper.js
Error:
/home/hafi/moz-work/src/obj-x86_64-unknown-linux-gnu/suite/installer/package-manifest:264:
Missing file(s): bin/components/NavigatorPropertyHelper.manifest

Bug anlegen lohnt wohl nicht.

Hartmut
--
Usenet-ABC-Wiki http://www.usenet-abc.de/wiki/
Von Usern fuer User :-)

[Jens Hatlak]

Hartmut Figge schrieb:

> mein neues Build will nicht mit:

>(...)

> Bug anlegen lohnt wohl nicht.

Wieso? Weil keine automatischen Builds erstellt werden? Kein Bug, kein
Fix. Wenn es einen Bug mit Patch gibt, kann ein Entwickler, der selbst
bauen kann (zu denen geh�re auch ich wieder, seitdem ich gestern auf
VC2010 gewechselt bin), das lokal verifizieren, dem Patch ein r+ geben
und einchecken. Problem gel�st.

Hast du Lust, den Patch zu schreiben? :-)

MfG

Jens

P.S.: F�r TB scheint Bug 872478 angelegt worden zu sein.

--
Jens Hatlak <http://jens.hatlak.de/>
SeaMonkey Trunk Tracker <http://smtt.blogspot.com/>

[Hartmut Figge]

Jens Hatlak:

>Hartmut Figge schrieb:
>> mein neues Build will nicht mit:
>>(...)
>> Bug anlegen lohnt wohl nicht.
>
>Wieso?

Ein Bustage ist nicht zu �bersehen.

>Weil keine automatischen Builds erstellt werden?

Auch mit funktionierendem Tree kann es eine ganze Weile dauern, bis ein
Bustage bemerkt wird. Nicht jeder l�scht $OBJDIR. ;)

Ein Hinweis hier kann nicht schaden und ist informativ f�r die anderen.

>Kein Bug, kein Fix.

Gab es bisher zu jedem Bustage-Fix einen Bug? Hmmm...

>Wenn es einen Bug mit Patch gibt, kann ein Entwickler, der selbst
>bauen kann (zu denen geh�re auch ich wieder, seitdem ich gestern auf
>VC2010 gewechselt bin), das lokal verifizieren, dem Patch ein r+ geben
>und einchecken. Problem gel�st.

Ein Patch ist zum Bemerken des Fehlesr nicht notwendig. :-P

>Hast du Lust, den Patch zu schreiben? :-)

Netter Versuch. *g*

>P.S.: F�r TB scheint Bug 872478 angelegt worden zu sein.

Sieht so aus, ja.

[Hartmut Figge]

Hartmut Figge:
>Jens Hatlak:

>>P.S.: F�r TB scheint Bug 872478 angelegt worden zu sein.
>
>Sieht so aus, ja.

Bustage-Fix f�r TB ist da, aber nicht f�r SM. Daher
https://bugzilla.mozilla.org/show_bug.cgi?id=872478#c3

Ging daneben, weil ich mich auf auto-detect verlassen hatte. *g*
https://bugzilla.mozilla.org/show_bug.cgi?id=872478#c4

[Hartmut Figge]

Hartmut Figge:

>Bustage-Fix f�r TB ist da, aber nicht f�r SM. Daher
>https://bugzilla.mozilla.org/show_bug.cgi?id=872478#c3

Abwarten h�tte gen�gt...

>Ging daneben, weil ich mich auf auto-detect verlassen hatte. *g*
>https://bugzilla.mozilla.org/show_bug.cgi?id=872478#c4

...aber jetzt wei� ich wenigstens, wie man einen falschen MIME Typ und
das Patch-Flag nachtr�glich setzen kann. :)

[Jens Hatlak]

Hartmut Figge schrieb:
> Jens Hatlak:

>> Hast du Lust, den Patch zu schreiben? :-)
>
> Netter Versuch. *g*

Na, ein erfolgreicher ist doch mehr als nett! :-P SCNR

F�r's n�chste Mal:
<https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F>

MfG

Jens

[Hartmut Figge]

Jens Hatlak:

><https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F>

Beispiel für einen einfachen Patch, der nur eine einzige Datei betrifft:

cd hg-moz
diff -up src/pfad1/file ~/pfad2/file > ~/pfad3/patch_name

Anschließend testen, ob SM mit diesem Test gebaut werden kann und ob er
sich nach dem Starten vernünftig verhält.

Es scheint für dieses Szenario keinen Weg zu geben, einen gewöhnlichen
hg Patch zu erzeugen, denn meine Patche entstehen außerhalb von hg.

In der Tat sind solche fertigen hg Patche unbrauchbar für mich. Sie
müssen erst mittels 'hg export' konvertiert werden, bevor sie in mein
Build-System passen und ich z.B. ein Backout testen kann.

Fazit: es ist mir nicht möglich, einen normalen hg Patch zu erzeugen,
solange ich nicht vollständig zu hg wechsele. Was nicht in meiner
Absicht liegt. :)

[Hartmut Figge]

Jens Hatlak:

><https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F>

Beispiel f�r einen einfachen Patch, der nur eine einzige Datei betrifft:

cd hg-moz
diff -up src/pfad1/file ~/pfad2/file > ~/pfad3/patch_name

Anschlie�end testen, ob SM mit diesem Patch gebaut werden kann und ob er
sich nach dem Starten vern�nftig verh�lt.

Es scheint f�r dieses Szenario keinen Weg zu geben, einen gew�hnlichen
hg Patch zu erzeugen, denn meine Patche entstehen au�erhalb von hg.

In der Tat sind solche fertigen hg Patche unbrauchbar f�r mich. Sie
m�ssen erst mittels 'hg export' konvertiert werden, bevor sie in mein

Build-System passen und ich z.B. ein Backout testen kann.

Fazit: es ist mir nicht m�glich, einen normalen hg Patch zu erzeugen,
solange ich nicht vollst�ndig zu hg wechsele. Was nicht in meiner
Absicht liegt. :)