[SLIDE 1] Köszö3~ntök ismét mindenkit:) Az előadáson az ISO-tesztelésről lesz szó. [SLIDE 2] ulysses: nem jók a diák ... Mit is tesztelünk? Hajjaj, baj lesz? indítsátok újra a lernidet Akkor mehet tovább:) Az egyes kiadások előtt tesztelni kell a lemezképeket, mert kínos lenne ha hibás ISO-t adnának ki. [SLIDE 2] ja, a diák: http://people.ubuntu.com/~kelemeng/isotesting.pdf Legutóbb az Ubuntu 8.04.4 képfájlok tesztelése volt soron, nemsokára pedig a *buntu 10.04 ISO-k tesztelése jön, mivel hamarosan érkezik az Alpha 3 http://iso.qa.ubuntu.com/ Ez az oldal szolgál a tesztelés koordinálására. [SLIDE 3] A teszteléshez nem feltétlenül kell a saját gépünkre telepíteni az adott kiadást, lehet virtuális gépet is használni, azonban megvan a hátránya, hogy a hardverrel kapcsolatos problémák nem jönnek elő. Virtualizálni pedig többféle módon is lehet szó, KVM, VirtualBox, stb. Nylevismeret sem árt, hiszen a felfedezett hibákat jelenteni kell, erről sianis mesélt korábban. [SLIDE 4] Launchpad-azonosítóra a hibák jelentéséhez van szükség, az ISO trackerben egyelőre sajnos nem működik. https://wiki.ubuntu.com/Testing/ISO/Procedures Íme a tesztelés folyamata. Minden egyes tesztesethez van leírás, mit és hogyan kell csinálni, és van link a tesztelendő képfájlhoz is. Három opció van egy teztesetnél, itt lehet jelezni, ha valaki elkezdett egyet, sikerült neki, vagy nem sikerült. A Bug ID mezőkbe abugok azonosítóját kell írni értelemszerűen. Ha valaki tsztel, érdmes belépnie az #ubuntu-testing csatornára Itt sok emberrel kerülhet kapcsolatba, akik azonnal segítenek Nekem egyszer maga Steve Langasek írt egy teszt után, aki elég fontos és ismert ember az Ubuntu közösségben. Hogy egyszerűbb legyen a tesztelés, van egy jó kis segédeszközünk: a testrdive [SLIDE 5] Erről van egy szép kis magyar leírás http://mogorvamormota.hu/2009/11/16/testdrive/ Nemrég a fejlesztő, Dustin Kirkland is írt róla a blogjában: http://blog.dustinkirkland.com/2010/02/have-you-taken-lucid-for-testrive-yet.html A testdrive segítségével nagyon egyszerűvé válik a tesztelés, miután telepítettük, indíthatjuk konzolból és menüből is. Van egy menüje, ahol ki lehet választani a kívánt képfájlt, a testdrive pedig letölti, és el is indítja azonnal nekünk egy virtuális gépben. Két virtualizációs megoldást támogat, a KVM-et és a VirtualBoxot Innentől kezdve csak követni kell a teszteset leírását, és gyűjteni a hibákat:) Ha nincs kérdés az eddigiekhez, át is adnám a szót torosnak, aki az apportról fog mesélni. ulysses: sianisnak volt kérdése ;) Jó kérdés:) Nem, figyelni kell a különböző csatornákat (levelezőlista, wiki), általában két-három nappal előbb kerülnek ki az ISO-k. van még kérdés? Például február 25-án megjelenik az Alpha 3, tehát 21-én talán már kint lesznek az ISO-k és a tesztesetek. ha nincs, akkor át is venném a szót szóval, mint azt már ulysses említette, az Apport nevű eszközről lesz szó vagyis erről: https://wiki.ubuntu.com/Apport gondolom, aki korábban használt már windowst, az látott olyat, amikor egy program lefagyott (tehát viszonylag gyakran :P), hogy a windows felajánlotta a hibajelentés küldésének lehetőségét nos, ilyen van ubuntuban is már egy ideje ez az Apport az Apportnak pedig van egy konzolos eszköze is, apport-collect néven ami nagyon nagy segítséget tud jelenteni a bugjelentésnél ezt lehet használni iso testing során, de persze bármikor máskor is az apport egy nagyon okos eszköz aminek segítségével egy bughoz kapcsolódóan az összes szükséges logot el tudjuk küldeni egyetlen parancs kiadásával így: apport-collect hibaszám a hibaszámról korábban már beszélt sianis, ez gyakorlatilag a bug egyedi azonosítója mivel az apport intelligens eszköz, ezért majd szépen ő megnézi a launchpadon, hogy miről van szó, milyen csomaghoz jelentették be a bugot és az ennek megfelelő logfájlokat küldi át amikor először használjuk, akkor megkérdezi, hogy szeretnénk-e potenciálisan személyes jellegű adatokat is megosztani a bugreportban nyilván, amikor egy virtuális gépen tesztelünk egy friss iso-t akkor erre nyugodtan igent mondhatunk, hiszen nagy valószínűséggel a virtuális gépen belül semmilyen személyes adatunk nincs vagy ha van, akkor arról tudunk más a helyzet, ha a napi használatú gépünkön használjuk itt nyilván mindenki maga dönt, a helyzet függvényében ugyanakkor sokszor lehet olyan, hogy csak ezen adatok birtokában lehet egy bugot kijavítani szóval érdemes mérlegelni az apport-collectet használhatjuk a saját bugreportunkhoz de akár más hibabejelentésénél is én azt javaslom, hogy mielőtt beöntenénk az apport adatokat más bugreportjába előbb szóljunk hozzá a fórumban, és jelezzük, hogy mégis mit fogunk küldeni hogy azért küldjük az adatokat, mert nálunk is rossz vagy azért, mert nálunk más a hibajelenség vagy azért, mert nálunk jó és ha már itt tartunk a bugok egy része regresszió vagyis olyan, ami tegnap még ment ma meg már nem ilyenkor azzal segítünk a legtöbbet, ha a korábbi állapotról _is_ küldünk az apporttal adatokat hogy lássák a fejlesztők, mi változott a logokban a régebbi verzióját a csomagnak esetleg megtalálhatjuk a /var/cache/apt könyvtárban ha még nem töröltük vagy van egy másik trükk: ha a frissítés csak most érkezett, akkor bízhatunk abban, hogy még nem szinkronizált minden tükör ilyenkor megkeressük a csomagot itt: http://packages.ubuntu.com majd szépen végigszaglásszuk a tükröket mondjuk a lucid kernele esetében itt nézelődhetünk: http://packages.ubuntu.com/lucid/i386/linux-image-2.6.32-13-generic/download én például legutóbb a jugoszláv (ami nyilván szerb) tükörről tudtam még órákkal később is előző csomagot szedni nyilván nem a svéd tükörrel érdemes próbálkozni, ami világviszonylatban is az egyik legfrissebb hanem a volt keleti blokk országaival, vagy az egzotikus helyekkel végül pedig ha egy PPA tárolós csomagból akarunk előző verziót akkor könnyű dolgunk van mert ott minden előző build is fent van például a gwibber esetében ez itt van: https://launchpad.net/~gwibber-daily/+archive/ppa/+builds?build_text=&build_state=built szóval ilyenkor érdemes lehet azt megtenni, hogy nem csak a bugos verziót apportoljuk hanem a jót is persze kommentben elmagyarázzuk, hogy melyik-melyik és miért küldtünk kettőt aztán van olyan is, hogy látunk egy bugreportot olyan bugról, ami nálunk is jelentkezik de meggyőződésünk, hogy rossz helyre lett besorolva hogy az mondjuk nem kernel probléma, hanem compiz bug vagy éppen X ilyenkor az apport-collectet utasíthatjuk arra, hogy ne a bugreportban szereplő csomagnak megfelelően válogasson a logokból hanem mi megmondhatjuk neki, hogy inkább mihez kapcsolódóan küldje az adatokat erre szolgál a -p (vagy --package) kapcsoló ahol egyszerűen megadjuk a csomag nevét pl.: apport-collect -p bokros 123456 így a bokros csomaghoz kapcsolódó logokat fogja elküldeni és végül van még valami, ami talán eddig nem hangzott itt el ez pedig az irc jelentősége nem lehet eléggé hangsúlyozni az IRC fontosságát ha bizonytalanok vagyunk egy bugreport kapcsán egyszerűen menjünk fel a projekt irc csatornájára és mondjuk el a dilemmánkat a legtöbb esetben ott lesz egy hozzáértő, aki el fogja tudni nekünk mondani hogy milyen információkra van szüksége és mit csináljunk ne féljünk segítséget kérni, a saját dolgunkat is megkönnyítjük és a fejlesztőkét is persze ha egyértelmű a helyzet, akkor nem kell irc-re járkálni feleslegesen szóval összefoglalva tömören az eddigieket, ha jelentünk egy bugot, a hibajelentés mellett érdemes megtoldani apport adatokkal lehet, hogy nem lesz rájuk szükség de jó, ha ott van az is és mivel az egész egy konzol parancs, arányosan a hibajelentéshez képest már nem egy nagy meló nos, ennyit szerettem volna erről elmondani van esetleg valakinek akár ezzel, akár a korábbiakkal kapcsolatban kérdése? nos, ha nincs, akkor én részemről befejezettnek nyilvánítom ezt az előadást :)