Megjelent az openSUSE 11.1 beta3

Újdonságok

* Live CD-k x86 architektúrákra (GNOME és KDE)
* OpenOffice.org 3.0
* Mono 2.0
* Linux 2.6.27.1 (e1000e javítással)
* CUPS 1.3.9
* 11.1 grafikai elemek
* Amarok 2.0 beta 2
* Banshee 1.3.2
* GNOME 2.24

A teljes listához érdemes megtekinteni a distrowatch oldalát.

Az openSUSE 11.1 beta 3 már Mac OS X gépekre is telepíthető, míg a korábbi openSUSE kiadások nem megfelelően írták ki a partíciós táblát az MBR-be.

A KVM a kernelbeállítások módosítása miatt nem működik. Ezek a hibák a következő kiadásra javításra kerülnek.

Az OpenOffice.org 3.0 integráció folyamatos és a jelenlegi kiadás már sokkal jobb. A legbosszantóbb hibákat, így a továbbra is hiányzó ikonokat, a Java regisztrációt és a többi apróságot még javítani kell. A jelenlegi OpenOffice.org a következő hibákat tartalmazza:

* KDE és GNOME integráció nem működik,
* a GNOME gyorsindító nem működik,
* a lokalizációs fájlok nem frissültek az extra forrásokból,
* a választható csomagok nem igazán választhatók, mivel a registry fájlok nem megfelelően lettek elkülönítve,
* a felhasználói beállítások /usr/share/ooo3 szimbolikus hivatkozásokat tartalmaznak a valódi fájlok helyett, ami alapvetően nem hiba, mégis problémákat okozhat a jövőben,
* a pyuno komponensek nincsenek regisztrálva,
* a Suse-puzzler.xls nem megfelelően működik (a "Keverés" nem működik és egérrel sem lehet tologatni a részeket),
* hiányzik némi fejlesztés az ooo-build/bin/package-ooo és a korábbi OOo.spec fájlokból
* hiányzik az OOo-sdk kompatibilitás

Legbosszantóbb hibák

* nincsenek x86_64 LiveCD-k,
* nincs ppc telepítőkészlet,
* a telepítés közben az xorg.conf megsérül a következő esetekben:
(GeForce 6200TC/7300LE/7300SE/Go 7300, Intel 965G/965GM, Radeon, vmware). kerülő megoldás: parancssorban root felhasználóként az init 3, sax2 -r, init 5 parancsok használata,
* a képernyővédő miatt összeomlik a gdm,
* a su és a parancssori bejelentkezés nem működik, kerülő megoldás: sudo vi /etc/pam.d/common-auth és el kell távolítani a pam_fp sort, hamarosan megjelenik ebből egy friss verzió,
* dbus-1 hiba, hamarosan ebből is lesz friss verzió,
* az sbl alapértelmezésként települ és elindul,
* a gdm automatikus bejelentkezés nem működik,
* a XEN nem működik [rengeteg hibabejelentés van ezzel kapcsolatban].

Tesztelési feladatok

A fejlesztőcsapat célja természetesen az, hogy az openSUSE 11.1 az eddigi legjobb kiadás legyen, ehhez azonban tesztelőkre van szükség, ezért bátorítani szeretnénk mindenkit, hogy töltse le és tesztelje a kiadást a rutinszerűen használt folyamatokkal. Felhívjuk a figyelmet, hogy ez még mindig egy fejlesztői kiadás, ezért ennek megfelelően kell használni.

Akik szeretnének részt venni a tesztelésben, azok előre elkészített tesztesetek találhatnak a Testing oldalon.

A fejlesztéssel kapcsolatos visszajelzéseket az opensuse-factory @ opensuse ! org levelezési listára lehet küldeni, valamint a kapcsolatfelvételre az #opensuse-factory IRC-csatorna is használható.

Letöltés

Az openSUSE 11.1 beta 3 i386, x86-64 PPC platformhoz érhető el. A telepítéshez szükséges médiák a hivatalos magyar FTP oldalon kívül az openSUSE oldalán is megtalálhatók.

Mérföldkövek

* 2008.10.30. - beta 4
* 2008.11.13. - RC1
* 2008.11.27. - RC2
* 2008.12.04. - Gold Master
* 2008.12.18. - Megjelenés

Lokalizáció

A beta3 kiadásból is számos fordítás kimaradt. ennek egyik oka, hogy egyszerűen nem készültek el a fordítások, másik oka pedig, hogy az utolsó pillanatban a fejlesztők még egy nagyobb adag forrást szabadítottak fel. Rosszabb hír, hogy beta4 sem lesz sokkal jobb. Ezért már csak az RC1-ben várható a teljes fordítás megjelenése.

A lokalizációval kapcsolatos kérdések, feladatok, ütemtervek megvitatása az opensuse-translation-hu @ opensuse ! org levelezési listán lehetséges.

Miért késett az openSUSE 11.1 beta 3 megjelenése?

Mint azt már korábban már bejelentették, a beta 3 kiadás az ütemtervekhez képest késett. Mivel rengeteg kérdés merült fel ezzel kapcsolatban, ezért egy részletes magyarázat mindenképpen érdekes lehet.

Egy kiadás során a következő lépések történnek:
* Péntek délután az autobuild team átnézi és ellenőrzi az összes csomagot, amely kiadásra vár. Mivel az autobuild team Nürnbergben található a péntek délután 15:00 CET/CEST, a hétfő este pedig 18:00 CET/CEST jelent.
* A hétvégén minden kiadásra bocsátott csomag fordításra kerül (vagyis forrásból bináris készül).
* Ennek megfelelően hétfőn reggelre előáll egy telepítőkészlet, amelyen tesztelni lehet, hogy megfelelően végigmegy a telepítés és a csomagok valóban telepítésre kerülnek-e.
* Amennyiben a tesztelés során hiba történik az a bugzillába kerül.
* Hétfő délutánra a tesztelés során található hibák javításra kerülnek (pl. a csomag nem fordult le, vagy a telepítés sikertelen. Ha nincs komoly probléma az alaprendszerben az autobuild team csak a néhány új csomagot fordítja újra. Mivel a disztribúció 4000 csomagot tartalmaz ezért hétfő este csak 2000 csomagnál kevesebbet célszerű újrafordítani. Kritikus hibák javítása mellett az ezekhez kapcsolódó csomagok és újrafordításra kerülnek
* A hétfői újrafordítások száma limitált, hogy kedd reggelre előállhasson egy újabb tesztelhető kiadás, amelyben már benne vannak az előző napi javítások, így a kiadásvezető és minőség-ellenőrző mérnökök újra megvizsgálják ennek telepíthetőségét. Ha ez rendben lement, akkor a kiadás előtti ellenőrzések kezdődnek meg.
* Ha ez első tesztek nem futnak le, és blocker (tesztelést megakadályozó) vagy stopper (kiadást megakadályozó) hibák jelennek meg, akkor ezek a bugzillába kerülnek a legmagasabb prioritással. Ezek javítása után újra készül egy kiadás, mindaddig míg az kiadásra alkalmasnak tekinthető.
* Általában a keddi kiadásokban talált hibák már kedd délutánra javításra kerülnek és aznap elkészül az új kiadás, ami tesztelhető.
* A kiadást megelőző sikeres tesztek után kiadásra kerül egy nem publikus telepítőkészlet, amelyet többen tesztelnek. Amennyiben nincs semmilyen kritikus hiba, a kiadási folyamat továbblépéseként a telepítőkészletek kikerülnek és megkezdődik azok szinkronizációja a különböző kiszolgálókra az interneten, így csütörtökre már mindenki számára elérhető.

A kiadást megelőző, valamint a belső teszteken is számtalan hibát találunk. Ezek a hibák nem kerülnek azonnal kijavításra, hanem bekerül a Legbosszantóbb hibák listájára, így a többi tesztelő már tud róluk. Csak a valóban blocker és stopper hibákat lehet ilyenkor javítani. Ha mindig minden hiba javíításra kerülne, akkor sosem jelenne meg a beta :) Természetesen ez nem azt jelenti, hogy a többi hiba nem kerül javításra, de ezek miatt nem áll meg a beta kiadások folyamata.

A disztribúció készítésének stabilizálása

Az első két beta kiadásban általában számtalan integrációs hiba van, mivel mindenki a saját fejlesztésére koncentrál és így kerülnek be a csomagok a disztribúció forrásába. Már az alpha kiadások során elkezdődik az integráció, de a Beta1 előtt lehetetlen ezt elvégezni, mivel a források folyamatosan és jelentősen változnak.

Azzal, hogy a disztribúció készítése átállt az openSUSE Build Service-re (és ez már a 3- beat kiadás, amely ezen készül), sokkal egyszerűbb egy kiadás elkészítése, bár ez nem véd meg attól, hogy egy kritikus hétvégén ne menjen el az áramforrás.

az openSUSE Build Service használata

A beta 1 kiadás óta az openSUSE Build Service készíti a kiadásokat és az ehhez tartozó telepítőkészleteket, a régi autobuild rendszer helyett. Ez mindenképpen felgyorsította a kiadás folyamatát, de még mindig vannak hibák, ami csak az telepítés tesztelésével kerülnek elő. A telepítőkészletek készítésekor számos változás történt, amely leegyszerűsíti a folyamatokat és jelenleg egyre több és több dolgot várunk el el ettől az új technológiától.

Korábban a telepítőkészleteket egy parancsfájl készítette, amelyet az autobuild team indított. Az egész folyamat ma már teljesen automatikus, így az openSUSE Build Service automatikusan nekiáll a telepítőkészleteknek, amint az ehhez szükséges csomagok fordításai elkészültek. Ez azt jelenti, hogy egy csomag módosítását követően automatikusan elkészül az új telepítőkészlet.

Kiadások számozása

Minden kiadás egyedileg azonosítva van egy számmal és a bugzillában is ezt használják (pl. beta 3 build 76, de ez nem azt jelenti, hogy ez a beta 3 76. verziója. A számozás valamikor a beta kiadások előtt kezdődik és amikor a 76-os build beta 3-ként jelenik meg, onnan kezdve mindenki erre hivatkozik).

openSUSE 11.1 Beta3 kiadás csúszása

Mi történt a Beta2 és a Beta3 kiadásokkal? Miért nem jelentek meg időben?
Számtalan esemény közös hatása okozta a késést:
* Az áramkimaradást követően az egyik build kiszolgáló megsérült és nem tudta befejezni a folyamatot és ez leállította az erre épülő többi folyamatot.
* Az áramkimaradás miatt csak hétfőn kezdődhetett el az összes csomag fordítása, amely egy 48 órás folyamat, ami azt jelenti, hogy ez az áramkimaradás 4 napba került a kiadás szempontjából.
* Hiba történt a metaadatok módosítása közben. A módosítás egy tervezett folyamat volt és érintette a YaST telepítőt és build systemet is.
* Néhány olyan csomag, amely elengedhetetlen volt a disztribúcióhoz egyszerűen nem készült el és ezek miatt újra kellett indítani a folyamatot
* Néhány csomag hibája más csomagokat is érintett, így ezeket is ki kellett javítani.
* A hibákat, jellegükből adódóan nem sikerült egyetlen nap alatt kijavítani.
* A disztribúció készítése közben függőségi hurkok keletkeztek, amely jelentősen megnövelte a folyamat idejét

Összefoglalva a beta 3 sokkal több tesztelést igényelt, mint a szokásos körülmények között.

Miért csütörtökön?

A matematikában jártas emberek számára mindezek után világos, hogyha minden rendben halad, akkor keddre elkészül egy működő kiadás. Ha nem megy minden simán akkor még egy napra van szükség, így a kiadás napja csütörtökön van. A későbbiek során nagyobb mozgásteret kell hagynunk a kiadásoknak az ehhez hasonló események miatt. Az RC kiadásoknál pedig már nincs a hétfői határidő így sokkal több hiba kerül javításra.

Miért kell minden csomagot újrafordítani?

Minden csomag, amelyben módosítás történik újrafordításra kerül és az ezekre épülő csomagok is mindaddig, amíg már nincs mit újrafordítani. ez azt jelenti, hogy egy új GCC csomag a teljes disztribúció újrafordítását eredményezi.

Ennek az az előnye, hogy a csomagok biztosan képesek egyetlen rendszerként működni, ha egy csomagban megváltozik az API vagy az ABI, az újraépítés során számtalan probléma kiderül. Ez segít a disztribúció konzisztenciájának megőrzésében.