Finally I have finished the translation of the UPGRADING doc.

1 files changed, 348 insertions, 202 deletions

diff --git a/messages/hu/UPGRADING.hu b/messages/hu/UPGRADING.hu
index e15bcb6a..2678352e 100644
--- a/messages/hu/UPGRADING.hu
+++ b/messages/hu/UPGRADING.hu
@@ -1,241 +1,387 @@
 Mailman - The GNU Mailing List Management System
-Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc.
+Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
 
 
-FRISSÍTÉS KORÁBBI VERZIÓKRÓL
-
-    A legtöbb esetben a Mailman frissítése nem több mint egy újabb
-    verzió telepítése a meglévő verzióra. Azonban néhány esetben
-    saját kezüleg kell gondoskodni a módosításokról.
-
-    What you need to do depends on the version you are using and the
-    version you are upgrading to.  In all cases, you should first turn
-    off your mail and web access to your Mailman installation.  You're
-    essentially upgrading a database, and it's usually a good idea to
-    make sure the database cannot be modified in the middle of the
-    upgrade.
-
-    A következőket ajánlom
-
-    - Kapcsoljuk ki a bejövő leveleket fogadó levelező démont. A legtöbb
-      távoli smtp kiszolgáló várakozó listába teszi a leveleket, ha a
-      25-ös port nem válaszol.
-
-    - Kapcsoljuk ki átmenetileg a Mailman webfelületét. Ez meg tehetjük,
-      úgy hogy a webkiszolgálót átmenetileg leállítjuk, vagy úgy hogy
-      a Mailman lapokhoz érkező kéréseket ideiglenesen átirányítjuk egy
-      "szolgáltatás nem érhető el" lapra. Ennek a beállításához kérjük
-      olvasd el a webszervered dokumentációját.
-
-    Mailman will NOT upgrade the template files for existing lists.
-    Chuq Von Rospach gives some useful advice in this message to the
-    users mailing list:
-
-    http://mail.python.org/pipermail/mailman-users/2000-September/006826.html
-
-    [Actually, the upgrade to MM2.1a2 /will/ shuffle template files,
-     deleting any that it detects are unchanged from the original
-     defaults (calculated via md5 checksums).]
-
-
-FRISSÍTÉS 2.0.x-RŐL 2.1-RE
+MEGJEGYZÉS A MODERÁLÁSHOZ
 
-    A 2.1-es Mailman 
-    In Mailman 2.1, the qrunner subsystem has been completely
-    rewritten.  You no longer start qrunner from cron!  Instead, there
-    is a bin/mailmanctl script which is used to start, stop, and
-    restart mail delivery.  This script is appropriate to use as a
-    Unix init script.  Be sure to update your crontab with the new
-    cron/crontab.in file.
+    2.0.x verzióról 2.1 verzióra történő frissítéskor ellenőrizzük,
+    hogy a moderálási és a privát beállítások nem térnek-e el a
+    korábban beállított értékektől. A moderálási és privát beállítások,
+    a könnyebb érthetőség és kezelhetőség érdekében, jelentősen
+    megváltoztak a Mailman újabb verziójában. Hiába azonban az
+    igyekezet, hogy minél tökéletesebben, problémamentesen kerüljenek
+    át a régi, összetett beállítások az új rendszerbe, mégis elő-
+    fordulhat, hogy a beállítások átvétele hibás lesz.
 
-    NOTE: It is very important that if you are upgrading from a
-    pre-MM2.1alpha2 system to a post-MM2.1alpha2 system that you let
-    the old qrunner process clear any and all messages sitting in the
-    qfiles/ directory *BEFORE* you upgrade.  Otherwise after the
-    upgrade, those messages will not get delivered, and I'm not
-    exactly sure yet how to upgrade those pending messages.
+    Különösen a (Privát beállítások -> Feladók szűrése)
+    default_member_moderation, generic_nonmember_action, és
+    accept_these_nonmembers beállításokat ellenőrizzük le. Ezenfelül 
+    célszerű ellenőriznünk a Listatagok kezelése menüben a fel-
+    használók egyenkénti moderálási állapotát is.
 
-    NOTE: When upgrading to Mailman 2.1beta1, you will need to
-    regenerate your aliases files.  There have been many changes to
-    the alias names, the programs they map to, and the name of the
-    wrapper script.  See README.<yourMTA> for details of making
-    Mailman work with your mail server.
 
-    To regenerate your aliases, use the bin/genaliases script.
-
-    Mailman 2.1 introduces multilingual (a.k.a. internationalization
-    or i18n) support.  Previously only one language per list was
-    supported, and it was assumed that this language would be English.
-    The upgrade script for Mailman 2.1 creates a subdirectory `en'
-    inside each lists/<listname> directory.  It then copies all the
-    .txt and .html files from lists/<listname> into
-    lists/<listname>/en.
-
-    If you have modified those templates to contain non-English text,
-    you will have to manually rename the en subdirectories to the
-    language code for the language of your templates.  Mailman's
-    upgrade script should handle cleaning up any templates which are
-    duplicates of the defaults, but you'll want to double check this
-    manually. 
-
-
-FRISSÍTÉS 2.0-RÓL 2.0.1-RE
-
-    Semmi mást nem kell csinálni, mint futtatni a "make install"
-    parancsot.
-
-
-UPGRADING FROM 2.0 beta to 2.0 final
-
-    You MUST re-run configure; running config.status is not sufficient
-    due to some recent changes in the autoconf scripts.  You can do a
-    head of config.status if you don't remember the options you
-    originally ran configure with.
-
-    The cron jobs for Mailman 2.0 final have changed considerably,
-    including the frequency with which they run.  You should reload
-    misc/crontab.in for the `mailman' user to get the right settings.
-    See the INSTALL file for details.
-
-    FAILURE TO DO THIS WILL RESULT IN A LESS THAN OPTIMALLY FUNCTIONAL
-    MAILMAN INSTALLATION.
+FRISSÍTÉS KORÁBBI VERZIÓKRÓL
 
+    A Mailman frissítése többnyire nem jelent mást, mint egy újabb
+    verzió telepítését a létező telepített verzióra. Azonban néhány
+    esetben saját magunknak kell bizonyos változtatásokat elvégeznünk.
 
-UPGRADING FROM 1.x to 2.x
+    Azt hogy egész pontosan mit kell csinálnunk az függ attól, hogy
+    melyik verzióról melyik verzióra állunk át. Mindegyik esetben 
+    először kapcsoljuk ki az e-mail és web hozzáférést a telepített
+    Mailmanhez, mivel lényegében egy adatbázis frissítünk és nem
+    lenne szerencsés ha frissítés közepén az adatbázisunk megváltozik.
 
-    In addition to the instructions above, I highly recommend that you
-    make sure your Mailman queue is cleared /before/ upgrading.
+    A következőket javasoljuk :
 
-    Mailman version 1.x had a cron script called run_queue which was
-    part of its bulk mailer.  With Mailman 2.x there is no default
-    bulk mailer (it lets the MTA handle this), and it is currently
-    unknown what the effects of upgrading are on the run_queue script,
-    but I'll bet it's not good. :)
+    - Kapcsoljuk le a bejövő levelekért felelős mail deamont. A legtöbb
+      smtp kiszolgáló megpróbálja később továbbítani nekünk a leveleket,
+      ha lezártuk a 25-ös portot.
 
-    The way to make sure that your Mailman queue is empty is to look
-    in your $prefix/data directory.  If you see any files that start
-    with "mm_q." you've still got messages waiting on the queue.  You
-    can run $prefix/cron/run_queue by hand until the queue is cleared.
-    Multiple invocations of this script won't help though; they lock
-    each other out.  Also, be warned that clearing the queue can take
-    a while and may cause a large load on your system (two reasons why
-    all this stuff has been redesigned in 2.x :).
+    - Átmenetileg kapcsoljuk ki a web hozzáférést is a telepített
+      Mailmanhez. Ezt elérhetjük úgy, hogy vagy ideiglenesen leállítjuk
+      a web kiszolgálót, vagy létrehozunk egy "átmenetileg szünetel"
+      oldalt a Mailman URL-ökhöz. Bővebb információkért olvassuk el
+      a web kiszolgálónk dokumentációját.
+     
+    Működő listák sablonállományait nem frissíti a Mailman. Hogy ilyen
+    esetben mit kell csinálni, azt Chuq Von Rospach leírásából lehet
+    megtudni a következő címen:
 
-    You do not need to run "make update" if you are upgrading from
-    version 1.0 or 1.1 to version 2.0, since this is now run
-    automatically when you do a "make install".  However you should
-    modify your crontab entries to execute cron/qrunner instead of
-    cron/run_queue.  You can also safely remove the file
-    $prefix/cron/run_queue.
+    http://mail.python.org/pipermail/mailman-users/2000-September/006826.html
 
-    If you are upgrading from a pre-1.0 beta, you need to follow the
-    instructions below.
+    [Valójában MM2.1a2 verzióra történő váltáskor a program lecseréli
+     a sablonállományokat, azokat pedig törli amelyek megegyeznek az
+     eredeti változattal (az összehasonlítást az md5 ellenőrzőösszegek
+     alapján végzi).]
+
+
+FRISSÍTÉS 2.0.x VERZIÓRÓL 2.1 VERZIÓRA
+
+    A Mailman 2.1-es verziójában drasztikus változtatáson esett át a
+    qrunner rendszer. A qrunnert többé nem cron-ból kell indítani!
+    Helyette a bin/mailmanctl program indításával vagy leállításával
+    lehet kezelni a levelek feldolgozását. A program egyben egy
+    Unix indító szkript is. Fontos, hogy el ne felejtsük frissíteni
+    a crontab bejegyzést az új cron/crontab.in állománnyal.
+
+    MEGJEGYZÉS: Nagyon fontos, hogy *MIELŐTT* frissítenénk MM2.1alpha2
+    előtti verzióról MM2.1alpha2-nél újabb verzióra, akkor hagyjuk 
+    hogy a régi qrunner folyamat a qfiles/ könyvtárban található
+    összes kézbesítésre váró üzenetet feldolgozza, mert a frissítés
+    után már nem fogja feldolgozni ezeket az üzeneteket az új qrunner.
+
+    MEGJEGYZÉS: Mailman 2.1beta1-nél újabb verzióra való átálláskor
+    újra létre kell hoznunk az aliases állományokat, mivel az újabb
+    verziókban a wrapper program neve megváltozott mailman-re. A
+    README.<MTAnk>.hu állományokban részletes leírás található a
+    Mailman és az adott levelezőszerver összekapcsolásáról.
+
+    Az aliases állományt a bin/genaliases programmal könnyen újra 
+    létre lehet hozni.
+
+    A 2.1-es Mailman már többféle nyelven is használható, támogatja
+    az eltérő karakterkészleteket. Régebbi verziókban listánként
+    mindössze egy nyelv volt használható és az is az angol volt. A
+    frissítés során minden egyes lista lists/<listanév> könyvtárába
+    létrehoz egy `en' nevű könyvtárat a program. A frissítés során a 
+    lists/<listanév> könyvtárakban található .txt és .html állományokat
+    bemásolja a program a lists/<listanév>/en könyvtárba.
+
+    Ha módosítottuk a sablonokat, hogy ne (csak) angol szöveget 
+    tartalmazzanak, akkor saját magunknak kell átnevezni az `en'
+    könyvtárat a használt nyelv kódjának megfelelő nevű könyvtárrá.
+    A Mailman frissítéseket végző programja automatikusan törli azokat
+    a sablonokat, amelyek több, azonos példányban is megtalálhatóak,
+    de nem árt személyesen is átfutnunk a sablonállományok listáját
+    ellenőrzésképpen.
+    
+    Ha 2.0.x-es rendszert használunk nem a szokványos javításokkal,
+    akkor a frissítés során problémákba ütközhetünk. Ilyenek lehetnek:
+
+    - Ha a #413752 (mindig sima szövegformátum) javítást telepítettük,
+      akkor a frissítés nem fog gond nélkül zajlani. A #651406 frissítés
+      segíthet a probléma megoldásában.
+	
+      http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=413752
+      http://sf.net/tracker/?group_id=103&atid=300103&func=detail&aid=651406
+
+
+LISTÁK EGYENKÉNTI FRISSÍTÉSE
+
+    Ha félünk a 2.1-es verzióra történő teljes átállásból eredő problé-
+    máktól, akkor megtehetjük hogy a listáinkat egyenkét frissítjük az 
+    újabb verzióra. Ehhez mindössze egy üres könyvtárba kell telepítenünk
+    a Mailman 2.1-es verzióját, erre a könyvtárra $MM21 -ként fogunk a
+    későbbiekben hivatkozni. (A 2.0-ás verzió könyvtárára pedig a 
+    továbbiakban $MM20 -ként hivatkozunk.)
 
+    Ilyen esetben a Mailman 2.0 és 2.1-es verziója egyszerre fog
+    működni a rendszerünkön addig, amíg teljes egészében át nem állunk
+    a 2.1-es verzióra. Az általunk használt MTA és web kiszolgálóktól
+    függően ez a módszer gond nélkül, simán is működhet, azonban elő-
+    fordulhatnak komoly problémák is.
 
-UPGRADING FROM PRE-1.0 to 2.x
+    Ha az Apache kiszolgálónál a mod_rewrite funkciót tudjuk használni,
+    akkor beállíthatjuk, hogy mind a 2.0-ás és 2.1-es Mailman ugyanazt
+    a /mailman és /pipermail címet használhassa; ezzel elérhetjük hogy
+    a lista adminisztrátorok, a felhasználók zavartalanul tudják 
+    használni a rendszert. 
 
-    You need to do a few extra things to make sure that the file
-    system layout for the early 1.0 betas is upgraded to the 1.x
-    configuration.  There are two ways to do this.
+    Minden egyes listánál, amelyet a másik verzióba akarunk átvinni
+    a következőket tegyük.
 
-    First, from the source directory, after you've done a "make
-    install" you can run "make update".  "make update" creates a file
-    named "update.log" in the top level of the source distribution.
-    If the script that updates the Mailman filesystem encounters
-    something that is not resolvable, it will log info about this to
-    "update.log".  This is worth checking after the upgrade completes.
+      * Állítsuk le az MTA-t.
 
-    You can also just change to the installation directory (i.e. $prefix)
-    and run bin/update.  This is the same as above except that the
-    update.log file is not generated.
+        Ha a kimenő forgalmunk számottevő, akkor megtehetjük, hogy
+	úgy állítjuk be az MTA-t, hogy csak a 127.0.0.1 (localhost)
+	címről érkező kapcsolatokat fogadja, így a 2.0-ás Mailman a
+	várakozó leveleket kézbesíteni tudja. Hogy ezt a beállítást,
+	hogyan tudjuk megtenni az függ a használt MTA-tól; Exim esetén
+	a "local_interfaces = 127.0.0.1" sort kell megadnunk, majd
+	"kill -HUP" paranccsal újraindítanunk az Exim démont.
 
-    Check your crontab entry.  Remove any runs of obsolete scripts, in
-    particular cron/upvolumes_yearly, cron/upvolumes_monthly, or
-    cron/archive.
+      * Állítsuk le a webkiszolgálót. Jobb megoldás, ha csak a /mailman/
+        oldalakhoz érkező kéréseket irányítjuk át egy "átmenetileg
+	nem elérhető" oldalra, ettől még más oldalakat el fognak 
+	tudni érni a felhasználók.
 
+        A megoldás itt is programfüggő; Apache esetén a mod_rewrite
+	segítségével az alábbi módon oldható meg:
 
-WHAT "MAKE UPDATE" DOES
+          RewriteRule ^/mailman/.* /var/www/unavailable.html [L]
+
+        (Természetesen előbb létre kell hoznunk a 
+        /var/www/unavailable.html oldalt.)
+
+      * Kényszerítsük a 2.0-ás Mailmant, hogy dolgozza fel a várakozó
+        leveleket a következő paranccsal:
+
+          python -S $MM20/cron/qrunner
+
+        (Ezt csak akkor kell megtennünk, ha a $MM20/qfiles könyvtár
+	nem üres, azonban győződjünk meg ekkor, hogy az MTA képes
+	fogadni kapcsolatot a 127.0.0.1 címről.)
+
+      * Mozgassuk át a listát:
+
+          cd $MM20
+          mv -i lists/foo-list $MM21/lists
+          mv -i archives/private/foo-list $MM21/archives/private
+          mv -i archives/private/foo-list.mbox $MM21/archives/private
+          rm archives/public/foo-list
+          rm archives/public/foo-list.mbox
+          cd $MM21
+          bin/withlist -l -r fix_url mylist
+
+        (Az utolsó lépés, a fix_url használata csak akkor szükséges,
+	ha a 2.0-ás és 2.1-es verziók eltérő URL-t használnak.)
 
-    Below is an annotated listing of the things that "make update"
-    does.  Hopefully, this will help resolve any problems you are
-    having.
+      * Módosítsuk a web kiszolgáló beállítását, hogy a listák 
+        oldalai elérhetőek legyenek. Két megoldás lehet; az egyszerűbb
+	az, hogy egy új címen keresztül érjük el a 2.1-es verziót,
+	pl. /mailman-21. Ehhez az Apache mod_rewrite modulját kell
+	használnunk:
+
+          RewriteRule /mailman/(.*)/(foo-list.*) /mailman-21/$1/$2 [R=temp]
+
+        (A [R=temp] rész azt jelenti, hogy a "/mailman-21/" cím csak
+	átmeneti és ha már minden listát átmozgattunk a 2.1-es 
+	verzióba, akkor megszűnik és az összes listát a "/mailman/" 
+	címen lehet majd elérni.)
+
+        A másik megoldásnál nem szeretnénk egy új címet használni,
+	hanem mind a 2.0-ás, mind a 2.1-es verzió listáit ugyanazon a
+	címen keresztül szeretnénk elérni. A megoldás ekkor az
+	Apache mod_rewrite moduljával a következő lehet:
 
-    Note that it can't hurt to run "make update" each time you
-    upgrade, but if you're running version 1.0 or newer, it won't help
-    much either!
+          RewriteRule ^/mailman/(.*)/(foo-list.*) \
+                      $MM21/cgi-bin/$1/$2 \
+                      [T=application/x-httpd-cgi]
 
-    - To upgrade to 1.0b10, you will need to copy
-      templates/options.html to lists/<listname>/options.html for each
-      mailing list you have.  However, if you have edited the
-      options.html file, say from the Web interface, you will have to
-      merge these changes in manually.
+        Ezen megoldás másik előnye, hogy gyorsabb is, mivel nem történik
+	átirányítás.
 
-    - The upgrade to 1.0b7 included the removal of
-      Mailman/smtplib.py{,c} since Mailman now uses the default Python
-      1.5.2 version of smtplib.
+	Bármelyik megoldást is alkalmazzuk el ne felejtkezzünk a lista
+	archívumának az átirányításáról sem:
 
-    - Archiving files are moved around as part of integrating
-      Pipermail into Mailman, as of 1.0b6.  In particular,
+          RewriteRule ^/pipermail/(foo-list.*) $MM21/archives/public/$1
 
-      1) if a list has only a private mbox archive
-      $prefix/archives/private/<listname> is moved to 
-      $prefix/archives/private/<listname>.mbox/<listname> 
+      * Indítsuk újra a web kiszolgálót (vagy kapcsoljuk ki az átirányítást,
+        amely az "átmenetileg szünetel" oldalt hozza be).
+
+      * Indítsuk újra az MTA-t (vagy állítsuk be, hogy mostantól már ne
+        csak a 127.0.0.1 címről fogadjon kapcsolatot).
+
+
+FRISSÍTÉS 2.0 VERZIÓRÓL 2.0.x VERZIÓRA (AHOL x >= 1)
 
-      2) if a list has only a public mbox archive
-      $prefix/archives/public/<listname> is moved to
-      $prefix/archives/private/<listname>.mbox/<listname>
+    Nem kell sok mindent tenni, a "make install" -lal a frissítés
+    is megtörténik.
 
-      and a symlink is made that points
-      $prefix/archives/public/<listname>.mbox to
-      $prefix/archives/private/<listname>.mbox/<listname>
 
-      3) if a list has both private and public mbox archives, 
-      make update picks one of the above 2 configurations based on
-      whether or not the list currently is archived publicly.  It then
-      renames the other mbox to mbox.preb6.
+FRISSÍTÉS 2.0 béta VERZIÓRÓL 2.0 végleges VERZIÓRA
 
-      4) if a list used recent CVS sources, where archives were placed in
-      $prefix/public_html/archives, then these are moved to
-      $prefix/archives/private/<listname> and a symlink is made from
-      $prefix/archives/public/<listname> to that spot if the list's
-      archives are public.  Also, a permissions-related security
-      problem is removed.
+    ÚJRA le kell futtatnunk a configure programot; a config.status 
+    újrafuttatása sajnos az autoconf programban történt változások
+    miatt nem elegendő. A config.status első sorai között meg
+    találhatjuk, hogy régebben milyen beállításokkal futtattuk le a
+    configure-t.
 
-      To integrate mbox archives of old lists, log in as user `mailman'
-      and run $prefix/bin/arch <listname> <path-to-mbox-archive>.
-
-      Also, by default, beta6 does both mbox and html based archiving,
-      but you can configure Mailman to do one, both, or neither.
-      Please see $prefix/Mailman/Defaults.py for details.
-
-      There was a short period of time when the CVS sources archiving
-      code was not organized into its own package.  The pickled
-      articles in the archives that were placed into archives during
-      this period stored the path to the module HyperArch, but that
-      module has moved.  You can quick fix this by running
+    A végleges 2.0-ás verzióban a cron feladatok és azok gyakorisága
+    megváltozott. A `mailman' felhasználónak újra be kell tölteni
+    a misc/crontab.in fájlból a helyes beállításokat. Bővebben
+    erről az INSTALL dokumentációban lehet olvasni.
+
+    HA KIHAGYJUK EZT A LÉPÉST, AKKOR A MAILMAN NEM FOG MEGFELELŐ
+    HATÉKONYSÁGGAL MŰKÖDNI.
+    
+
+FRISSÍTÉS 1.x VERZIÓRÓL 2.x VERZIÓRA
+
+    Erősen javasolt, hogy győződjünk meg a frissítés előtt, hogy
+    a Mailman feldolgozási sora üres.
+
+    A 1.x verzióban a levelek kézbesítését a run_queue program
+    végezte. A 2.x verziókban ez a program megszűnt (funkcióját
+    az MTA vette át), és jelenleg nem ismert, hogy milyen hatást
+    idéz elő a frissítés ezen a programrészen, de valószínű
+    hibás működéshez vezetne.
+
+    Ha a $prefix/data könyvtár üres, akkor a Mailman feldolgozási
+    sora biztosan üres. Ha a könyvtár "mm_q." kezdetű fájlokat
+    tartalmaz, akkor még mindig van kézbesítésre váró levél a 
+    feldolgozási sorban. A $prefix/cron/run_queue program indítá-
+    sával kényszeríteni lehet ezen levelek kézbesítését. A program 
+    többszöri indítása nem sietteti a feldolgozás idejét, mivel
+    a program párhuzamos feldolgozások elől zárolja a leveleket. 
+    Fontos megjegyeznünk, hogy a feldolgozási sor kiürítése időbe
+    kerül és a rendszert erősen terhelheti (ezért is lett átírva a
+    kézbesítés a 2.x verzióban).
+
+    Nem kell használni a "make update" parancsot, ha 1.0 vagy 1.1-ről
+    2.0-ára frissítünk, mert ezt a parancsot a "make install" automa-
+    tikusan lefuttatja. Viszont frissítenünk kell a crontab bejegyzéseket,
+    hogy ezentúl ne a cron/run_queue, hanem a cron/qrunner program
+    legyen időszakosan elindítva. Ezek után nyugodtan lehet törölni
+    a $prefix/cron/run_queue fájlt.
+
+    Ha egy 1.0 béta előtti verzióról szeretnénk frissíteni, akkor
+    azt a lejjebb található módon végezzük.
+
+
+FRISSÍTÉS PRE-1.0 VERZIÓRÓL 2.x VERZIÓRA
+
+    Az 1.0 béta előtti verziókról történő frissítéskor legelőször
+    a Mailman könyvtár rendszerét kell frissíteni, ezt két módon
+    tehetjük meg.
+
+    Első módszernél a forrás könyvtárában miután kiadtuk a "make 
+    install" parancsot, adjuk ki a "make update" parancsot. Ekkor 
+    létrejön egy "update.log" nevű állomány a forrás gyökér-
+    könyvtárába. Ha a program a Mailman fájlrendszer frissítésekor
+    olyan problémába ütközik, amelyet nem tud megoldani, akkor ebbe
+    az "update.log" állományba fogja menteni a hibaüzenetet. Célszerű
+    ezért ezt a fájlt frissítés után átnéznünk.
+
+    A frissítést végrehajthatjuk úgy is, hogy belépünk a telepített
+    Mailman könyvtárába (pl. $prefix) és futtatjuk a bun/update 
+    programot. Ez a program ugyanazt hajtja végre, mint az előbbi, 
+    de nem hozza létre az update.log fájlt.
+
+    Ellenőrizzük a crontab beállításokat. Töröljük a szükségtelen,
+    elavult programok indítására vonatkozó bejegyezéseket, elsősorban 
+    a cron/upvolumes_yearly, cron/upvolumes_monthly, vagy cron/archive
+    programokra utaló bejegyzéseket.
+
+
+A "MAKE UPDATE" MŰKÖDÉSE
+
+    A továbbiakban a "make update" működéséről, magyarázatokkal el-
+    látva olvashatunk. Reméljük, hogy ez segít az esetleges problémák
+    elhárításában.
+    
+    Jó tudni, hogy nem jelenthet problémát, ha minden egyes frissítéskor
+    kiadjuk a "make update" parancsot, azonban az 1.0-nál újabb verziók
+    esetén nem fog változást hozni!
+
+    - 1.0b10 verzióra történő frissítéskor a templates/options.html 
+      fájlt át kell másolni minden egyes listánál a lists/<listanév>/
+      könyvtárba. Ha módosítottuk az options.html fájlt - mondjuk a 
+      webfelületen keresztül -, akkor a változtatásokat saját magunknak
+      kell végrehajtani az új fájlokon.
+      
+    - 1.0b7 verzióra történő frissítéskor a Mailman/smtplib.py{,c}
+      állományokat törölni kell, a funkcióját a Python 1.5.2 verzióban
+      található smtplib veszi át.
+
+    - Az archívum helye az 1.0b6-os telepítésével megváltozik, mivel
+      ebben a verzióba a Pipermail már be lett építve. A teendők,
+
+      1) ha a listának csak privát mbox archívuma van, akkor a
+      $prefix/archives/private/<listanév> átkerül a
+      $prefix/archives/private/<listanév>.mbox/<listanév> helyre,
+
+      2) ha a listának csak nyilvános mbox arcívuma van, akkor a
+      $prefix/archives/public/<listanév> átkerül a
+      $prefix/archives/private/<listanév>.mbox/<listanév> helyre
+
+      és egy szimbolikus hivatkozást kell létrehozni, a
+      $prefix/archives/public/<listanév>.mbox hivatkozásnak a
+      $prefix/archives/private/<listanév>.mbox/<listanév> helyre kell mutatnia.
+      
+      3) ha a listának mindkét típusú archívuma létezik már, akkor
+      a "make update" a kettő közül attól függően azt választja, hogy
+      a lista éppen nyilvános vagy privát archívummal rendelkezik.
+      Ezek után a mások mbox-ot átnevezi mbox.preb6 -á.
+
+      4) ha a lista olyan CVS verziót használ, ahol az archívum helye
+      a $prefix/public_html/archives volt, akkor a program ezeket
+      a $prefix/archives/private/<listanév> helyre mozgatja át és
+      létrehozza a $prefix/archives/public/<listanév> szimbolikus
+      hivatkozást, ha a lista archívuma nyilvános. Ezzel egy 
+      jogosultsági probléma is megoldódik.
+
+      A régi listák archívumának létrehozásához lépjünk be `mailman'
+      felhasználóként és futassuk a következő parancsot:
+
+      $prefix/bin/arch <listanév> <mbox-archívum-elérési-útvonala>.
+       
+      Továbbá a beta6 alapértelmezés szerint az archívumot mind
+      mbox, mind html formátumban létrehozza. Hogy csak egyik, vagy 
+      mindkettő vagy semelyik módszer szerint se archiváljon az
+      a megfelelő helyen beállítható. Erről bővebben a 
+      $prefix/Mailman/Defaults.py állományban lehet olvasni.
+
+      A fejlesztések során volt egy olyan rövid időszak, amikor az
+      archiválást végző kód nem csak a saját csomagján belül volt
+      elhelyezve. Ekkor az archívumba elhelyezendő levelekhez a
+      HyperArch modulra is szükség volt, amelynek azóta a helye
+      megváltozott. A problémát a következő paranccsal lehet 
+      megoldani:
 
       ln -s $prefix/Mailman/Archiver/HyperArch.py \
-              $prefix/Mailman/HyperArch.py  
-
-    - If upgrading from version 1.0b4 or earlier, "make update" moves
-      list-specific templates.  For each list,
-      $prefix/templates/<listname>/* is moved to $prefix/lists/<listname>.
-      Please reference the generic templates in $prefix/templates to see
-      if any variables have changed (There shouldn't be many, only
-      options.html was updated from b5 to b6).
-
-      For really old versions of Mailman, you may not even have
-      <listname> subdirectories in $prefix/templates!  In this case
-      you will need to manually copy some files into your new list
-      directories.  Here's an example shell command that will do the
-      trick:
-
-      cp templates/{archives,handle_opts,listinfo,roster,subscribe}.html lists/<listname>
-
-    - Some modules that existed in previous versions, but that have
-      been replaced with newer (differently named) modules, are
-      removed.
+              $prefix/Mailman/HyperArch.py
+
+    - Ha 1.0b4 -nél régebbi verzióról frissítünk, akkor a "make update"
+      a lista-specifikus sablonokat ($prefix/templates/<listanév>/*) 
+      minden egyes listánál áthelyezi a $prefix/lists/<listanév> könyvtárba.
+      Ellenőrizzük, hogy a $prefix/templates könyvtárban maradó általános
+      sablon fájlok közül bármelyik is meg változott-e. (Elméletileg
+      csak az options.html változik meg a b5-ről b6 verzióra történő
+      átálláskor.)
+
+      Nagyon régi Mailman verzióknál még <listanév> alkönyvtár sem 
+      található a $prefix/templates könyvtárban! Ez esetben saját
+      magunknak kell bizonyos fájlokat átmásolni az új könyvtárba.
+      A következő parancs átmásolja a szükséges fájlokat:
+
+      cp templates/{archives,handle_opts,listinfo,roster,subscribe}.html lists/<listanév>
+
+    - Törölni kell azokat a modulokat, amelyek a korábbi verziókban
+      megtalálhatóak voltak, de az újabbakban le lettek cserélve,
+      vagy új nevet kaptak.