Ubuntu Suomen keskustelualueet
Ubuntun kehittäminen ja yhteisö => Ubuntun kehitysversio => Aiheen aloitti: qwertyy - 31.01.09 - klo:01.05
-
Onko täällä Launchpadin toimintaan perehtyneitä henkilöitä? En ole ohjelmoija, enkä siitä tiedä käytännössä oikein mitään, mutta olen silti yrittänyt hiukan osallistua toimintaan bugiraporttien kautta, sen mitä nyt osaan. Tällä hetkellä kiinnostaa mitä käytännössä on tapahtunut ja tulee tapahtumaan esim. tuolle bugiraportille, jonka tein HP:n suspendista? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/318546
Eli ilmeisesti noista lokitiedoista joku on saanut jotain irti ja vika tiedetään, kun tila päivittyi aivan hetki sitten "triaged" tilaan? Kuten mainittua en tiedä ohjelmoinnista mitään, mutta mielenkiinnosta haluaisin tietää, mikä tuon oikein sitten aiheuttaa, mutta en huomaa sivulla mitään muutosta. Vai onko joku nyt päättänyt, että noilla antamillani tiedoilla vian voi ratkaista, mutta asiaa ei ole selvitetty kuitenkaan vielä käytännössä lainkaan?
Oletettavasti minulta ei enää pyydetä lisätietoa tuon bugin suhteen esim. lisätestailua tuolla jauntyn live lätyllä? Asia kiinnostaa lähinnä sen takia, että parilla koneella tulee tehtyä omia empiirisiä testejä ja linux opiskelua, eli distro voi vaihtua melkein milloin vain tms. mutta en siis haluaisi tietenkään jättää raportointia "kesken". Tuossa koneen vieressä on kokoajan ollut tuo livecd valmiina jos tarvetta sille olisi....
-
Tällä hetkellä kiinnostaa mitä käytännössä on tapahtunut ja tulee tapahtumaan esim. tuolle bugiraportille, jonka tein HP:n suspendista?
Ilmeisesti siinä on kehittäjille tarpeellinen tieto, kun se on tilassa triaged. Jauntyn kernelin kohdalla tilaksi voi tulla fix-released, jos vika ehditään korjaamaan. Jos sitä ei ehditä korjaamaan, siitä tulee won't fix Jauntyn osalta. Silloin se voi saada Jaunty+1 osalta tilan incomplete. Tässä nyt ensin mieleen tulevat vaihtoehdot.
Oletettavasti minulta ei enää pyydetä lisätietoa tuon bugin suhteen esim. lisätestailua tuolla jauntyn live lätyllä?
Vika näyttäisi olevan kernelissä. Livelätyn kerneli ei päivity, joten sillä ei voi testata paljon enempää.
Asia kiinnostaa lähinnä sen takia, että parilla koneella tulee tehtyä omia empiirisiä testejä ja linux opiskelua, eli distro voi vaihtua melkein milloin vain tms. mutta en siis haluaisi tietenkään jättää raportointia "kesken".
Jos satut kokeilemaan muuta distroa, voit kommentoida toimiiko suspend siinä. "Also affects distribution" kohdasta voi lisätä distron, jos se ei toimi. En tiedä kuinka paljon siitä on hyötyä.
-
Muutamia raportteja olen myös sinne Launchpadiin tunkenut aikoinaan. Yleensä sinne on pitänyt jonkun toimesta sitten lisäillä lokeja, että pystyvät tutkimaan tarkemmin. Tosin siihen se on yleensä sitten aina jäänytkin ja yleisesti ottaen niihin sitten joku joskus vaivautuu useiden kuukausien jälkeen kyselemään, että toistuuko uudemmalla Ubuntun versiolla. Eli bugiraportointi omasta mielestäni tuntuu turhalta, kun ei niille ainakaa omissa kokemuksissa ole mitää tehty.
Tiedän, että bugeja tulee sinne valtavasti ja kaikkeen ei varmaan paukut riitä, mutta silti negatiivinen asia Ubuntussa. Minusta Ubuntu-teamin kannattaisi miettiä pidemmän syklin julkaisua, jolloin saataisiin valmiimpaa kauraa ulos ja myöskin bugeja korjailtua. Vuoden periodi olis paljon parempi kuin puolen vuoden, mutta tämähän on vain oma mielipiteeni.
Siksi hiukan negatiivinen sävy tässä kirjoituksessa, että Intrepidiin aikoinaan viime syyskuussa ilmoitettu bugi suspendista (syyskuussa alpha-versiolla, mutta edelleen toistuu) on edelleenkin tutkimatta. Launchpadissa on abouttiarallaa ainakin viisi duplikaattia / vastaavaa erroria, eikä niille ole tehty yhtikäs mitään. Minusta suspend kun kuitenkin on aika oleellinen asia, joka kuuluisi aika suurelle prioriteetille korjata. Koneessani kyllä toimasi 7.10 versiossa suspend, mutta 8.10 versiossa se on rikottu.
-
Eikös tuo suspend juttu ollut nimenomaan kernelin bugi, joka itse Linustakin otti päähän ja ratkesi vasta tuossa joulun alla. Korjaus lienee testivaiheessa, jos ei kerran vielä ole valunut Jauntyn kerneleihin.
Lähde:
http://torvalds-family.blogspot.com/2008/12/life-is-good-again.html (http://torvalds-family.blogspot.com/2008/12/life-is-good-again.html)
Tarkemmin en tiedä, missä mennään, muttta asiaa voi halutessaan seurata tuolla:
http://kernelnewbies.org/LinuxChanges (http://kernelnewbies.org/LinuxChanges)
T:Jallu59
-
Eikös tuo suspend juttu ollut nimenomaan kernelin bugi, joka itse Linustakin otti päähän ja ratkesi vasta tuossa joulun alla. Korjaus lienee testivaiheessa, jos ei kerran vielä ole valunut Jauntyn kerneleihin.
Lähde:
http://torvalds-family.blogspot.com/2008/12/life-is-good-again.html (http://torvalds-family.blogspot.com/2008/12/life-is-good-again.html)
Tarkemmin en tiedä, missä mennään, muttta asiaa voi halutessaan seurata tuolla:
http://kernelnewbies.org/LinuxChanges (http://kernelnewbies.org/LinuxChanges)
T:Jallu59
Aah.. no eipä kiinnostanut Ubuntun bugikorjaajia kertoa tuota :) Ei kauaa kestäisi kun sen tuonne bugiraporttiin ilmoittaisi.
Eli entistä surkeampaa toimintaa launchpadissa, kun tietoa ei viitsitä jakaa.
-
Tuotahan piti heti kokeilla. Eilen asentamassani Fedora 11 alfassa (http://forum.ubuntu-fi.org/index.php?topic=23086.msg187512#msg187512) (kernel 2.6.29-0.78.rc3.git5.fc11.i686) tuntuisivat sekä suspend että hibernate toimivan (EDIT: ainakin manuaalisesti kokeiltuna). Minkähän takia se ei muuten tehnyt oletuspartitioinnissa swappiä lainkaan?
-
Aah.. no eipä kiinnostanut Ubuntun bugikorjaajia kertoa tuota :) Ei kauaa kestäisi kun sen tuonne bugiraporttiin ilmoittaisi.
Eli entistä surkeampaa toimintaa launchpadissa, kun tietoa ei viitsitä jakaa.
Korjaajia on vaan niin vähän, että eivät aina ehdi tehdä kaikkea. Tekemäsi bugiraportin kohdalla on toiminta ollut jopa tavanomaista ripeämpää, kun raportin statusta on sentään muutettu. Minun tekemiini raprtteihin on saattanut tulla vastetta vasta neljän kuukaudenkin päästä.Otsikointi on tässä hommassa a&o. Jos otsikko ei herätä jonkun raportteja seuraavan kiinnostusta tuoreeltaan, se katsotaan sitten vasta myöhemmin ikäjärjestyksessä oletan.
T:Jallu59
-
No niin, nyt aletaan olla asian ytimessä :)
Korjaajia on vaan niin vähän, että eivät aina ehdi tehdä kaikkea.
Aivan.. Jos kerran on väen puutetta, niin miksi kaikki bugikorjaus jätetään heitteelle ja keskitytään vain uuteen releaseen? Eikö kannattaisi pitentää releasointi vaikkapa vuoteen, jolloin saataisiin bugejakin jopa korjattua?
Tekemäsi bugiraportin kohdalla on toiminta ollut jopa tavanomaista ripeämpää, kun raportin statusta on sentään muutettu.
Jos kerran raportin statusta muutetaan ja tieto on suoraan että kerneli on kuralla, niin eikö se kannattaisi ilmoittaa? Ei se kovin vaikeaa nimittäin ole launchpadissa etsiä sanalla suspend ja kirjoittaa jokaiseen copy-pastena että kerneliin 2.6.29 on korjaus luultavasti tulossa.
Minun tekemiini raprtteihin on saattanut tulla vastetta vasta neljän kuukaudenkin päästä.Otsikointi on tässä hommassa a&o. Jos otsikko ei herätä jonkun raportteja seuraavan kiinnostusta tuoreeltaan, se katsotaan sitten vasta myöhemmin ikäjärjestyksessä oletan.
Jos vaste on luokkaa neljä kuukautta ja release periodi on 6kk, niin ollaa metsässä jo suoraan. Jotain kannattaisi mielestäni muuttaa, että bugikorjaukseenkin panostettaisiin.
Tämä on omaa suoraa kritiikkiä Ubuntulle vaikkakin ihan kelpo Linux onkin. Ubuntua hehkutetaan varsinkin suomessa ns. ensikertalaisille helppokäyttöiseksi. Minusta laatuun kannattaisi panostaa, sillä kyllä omasta tottumuksesta saanen sanoa, että valmiimpaa kauraa tulee useammalta muulta distrolta. Ja tiedän että tällä omalla kritiikillä ei ole mitään vaikutusta täällä, mutta saanenpa sen ainakin sanoa :)
-
Debian stable saattaisi olla laadun mittapuu, mutta kun se tavara on jo niin vanhaa ;D
Laatua itsekin olen peräänkuuluttanut, jopa launchpadissa, mutta kun distro haluaa mennä kärkijunassa niin se on sitten tätä joskus.
Muiden suurimpien distrojen suhteen, joita olen kokeillut aika ajoin, on tilanne aivan samanlainen. Asia joka Ubuntussa bugaa toimii paremmin josasain toisessa, mutta taas joku toinen asia on poskellaan mikä Ubuntussa toimii. Vaikka tietyt Ubuntun nykyiset puutteet pännivät suuresti, ovat sen hyvät puolet toistaiseksi pitäneet minut distron parissa. Katastrofaalsisin asia Ubuntussa on tällä hetkellä näyttöjen tunnistuvuus/tunnistamattomuus ja käytös tunnistamnattomassa tilanteessa. Nykytila karkoittaa monet kokeilijat, kun näyttö ei toimi siedettävästi kättelyssä.
T:jallu59
-
Korjaajia on vaan niin vähän, että eivät aina ehdi tehdä kaikkea. Tekemäsi bugiraportin kohdalla on toiminta ollut jopa tavanomaista ripeämpää, kun raportin statusta on sentään muutettu. Minun tekemiini raprtteihin on saattanut tulla vastetta vasta neljän kuukaudenkin päästä.Otsikointi on tässä hommassa a&o. Jos otsikko ei herätä jonkun raportteja seuraavan kiinnostusta tuoreeltaan, se katsotaan sitten vasta myöhemmin ikäjärjestyksessä oletan.
Lisäksi vaikuttaa kuinka helposti bugi on toistettavissa, mitä pakettia vastaan se on raportoitu jne. Jotkut luokittelevat (triage) myös uusimpia bugeja tai laitteestoonsa vaikuttavia bugeja.
Tämän mukaan voi käydä luokittelemassa noita bugeja myös itse.
https://wiki.ubuntu.com/Bugs/Status
Kernelin bugien ratkaisua nopeuttaa, jos voi toistaa ne kehitysversiossa. Lisäksi jos pystyy selvittämään mikä patchi ratkaisee ongelman, se auttaa paljon.
-
Jos kerran raportin statusta muutetaan ja tieto on suoraan että kerneli on kuralla, niin eikö se kannattaisi ilmoittaa? Ei se kovin vaikeaa nimittäin ole launchpadissa etsiä sanalla suspend ja kirjoittaa jokaiseen copy-pastena että kerneliin 2.6.29 on korjaus luultavasti tulossa.
Kaikkien suspend ongelmien syy ei välttämättä ole sama. On sinänsä mahdollista, että tuo korjattu vika vaikuttaisi sinunkin laitteistoosi.
Jos on olemassa paikka tiettyyn vikaan, kysytään usein toimisiko uusi paketti. Joskus myös vanhoissa bugeissa kysytään onko vika vielä olemassa uudemmassa versiossa. Tässä suspend tapauksessa copy-paste tekniikasta ei taitaisi olla hyötyä.
Jos vaste on luokkaa neljä kuukautta ja release periodi on 6kk, niin ollaa metsässä jo suoraan. Jotain kannattaisi mielestäni muuttaa, että bugikorjaukseenkin panostettaisiin.
Missään ei taida olla yksinkertaista säädintä jakelun julkaisuajan ja vastausajan välillä. Pitempi julkaisuaikataulu saattaisi jopa lisätä bugeja ja hidastaa vastauksia bugiraportteihin. Toivoisin myös nopeampia vastauksia bugeihin. Välillä tosin saakin nopeita vastuksia.
-
Eikös tuo suspend juttu ollut nimenomaan kernelin bugi, joka itse Linustakin otti päähän ja ratkesi vasta tuossa joulun alla. Korjaus lienee testivaiheessa, jos ei kerran vielä ole valunut Jauntyn kerneleihin.
T:Jallu59
Oletetttavasti tätä minun halusivat testaavan tuolla alpha 3 livellä, jossa mielestäni oli joku > 28 versioinen kerneli, mutta sillä kone siis jämähti ihan lukkoon.
-
Kaikkien suspend ongelmien syy ei välttämättä ole sama. On sinänsä mahdollista, että tuo korjattu vika vaikuttaisi sinunkin laitteistoosi.
Jos on olemassa paikka tiettyyn vikaan, kysytään usein toimisiko uusi paketti. Joskus myös vanhoissa bugeissa kysytään onko vika vielä olemassa uudemmassa versiossa. Tässä suspend tapauksessa copy-paste tekniikasta ei taitaisi olla hyötyä.
No selvennetääs hiukan. Jos on tiedossa, että kernelissä on bugi, joka rikkoo suspendin, niin...
a) onko parempi sinusta olla hiljaa?
b) vaiko mahdollisesti copy pastena kertoa kaikkiin bugeihin, että kernelissä on vikaa, joka saattaa aiheuttaa tämän (huom. sana "saattaa")
Pitempi julkaisuaikataulu saattaisi jopa lisätä bugeja ja hidastaa vastauksia bugiraportteihin.
Perustelepa tuo, niin ehkä saatan uskoakin. Ainakin tällä hetkellä olen eri mieltä.
Edited: Lisätääs tähän viel, että tarkoituksenani ei ole mollata Ubuntua maan rakoon, vaan antaa omaa kritiikkiäni missä minun mielestäni olisi parannettavaa. Ubuntu on edelleen minulle se suosituin Linux..
-
No selvennetääs hiukan. Jos on tiedossa, että kernelissä on bugi, joka rikkoo suspendin, niin...
a) onko parempi sinusta olla hiljaa?
b) vaiko mahdollisesti copy pastena kertoa kaikkiin bugeihin, että kernelissä on vikaa, joka saattaa aiheuttaa tämän (huom. sana "saattaa")
Oletan, että kernelissä on useampia bugeja, mitkä aiheuttavat suspendin toimimattomuutta. Joihinkin laitteisiin suspend ominaisuutta ei ole tehty vielä. Jotkut viat näkyvät hyvin harvalla laitteella. Jos bugi luokitellaan olevan kernelissä, paketiksi valitaan linux.
Tässä tapauksessa:
a) On mielestäni parempi näistä kahdesta, jos ei ole tarkempaa tietoa kuin, kernelissä on vikaa.
b) Sopii mielestäni vasta tapauksiin, joissa vika on selvitetty ja on olemassa paketti jolla voi kokeilla onko vika vielä olemassa. Lisäksi automatisoidut viestit ovat joskus ongelmallisia.
Tapauksesta riippuen löytyy luultavasti näitä kumpaakin parempi vaihtoehto.
Joskus jo toiminut ominaisuus ei toimi enää (regression) ja vika voidaan todeta tulleen tiettyjen versioiden välissä. Silloin vian selvittäminen on helpompaa. Mitä vähemmän muutoksia versioiden välissä, sitä helpompi on eristää vika. Ohjelmien paketointi on työläämpää, jos pakettien välissä on paljon muutoksia. Ohjelmien pitäminen tarpeeksi uusina auttaa myös työskentelyä ohjelmien upstream versioiden kehittäjien kanssa. Se hyödyttää molempia osapuolia. Tässä muutama syy, miksi bugit saattaisivat jopa lisääntyä ja vastausaika pidentyä julkaisujen harventuessa. Vaikeahan sitä on arvioida. Launchpad tarjoaa myös mahdollisuuden upstream bugien liittämisen bugiraporttiin.
-
Toimiva bugien käsittely vaatii eritasoisia ihmisiä. Tarvitaan niitä bugiraportteja, mutta tarvitaan myös niitä ihmisiä jotka osaavat jalostaa usein "raa'asta" bugiraportista sellaisen raportin, että se sisältää tarvittavat tiedot. Sitten tarvitaan vielä ihminen joka asian osaa korjata, joka ei useinkaan välttämättä ole sama henkilö joka on nimellisesti paketin ylläpitäjä Ubuntussa. Korjaus pitää osata toimittaa paketin ylläpitäjälle/kehittäjälle mahdollisimman helpolla tavalla, ja sitten vielä paketin ylläpitäjän pitää ehtiä arvioimaan korjauksen luotettavuus, ottamaan se vastaan ja sisällyttää Ubuntuun.
Ubuntun bugien korjaaminen on yhteisötoimintaa siinä missä sekin, tuleeko täällä foorumeilla kysymyksiin vastauksia. Ja samoja lainalaisuuksia on, paitsi vielä isompina, eli yhtä aktiivista kehittäjää kohden voi olla 1000 bugiraporttia. Jos bugiraportti on luokkaa "ei toimi tällä koneella xyz", niin sille ei kehittäjä voi juuri tehdä mitään ellei ole sama kone käytettävissä jolla ongelman voisi toistaa. Tällöinkin ongelma voi johtua jostakin asiasta, jonka takia ongelmaa ei voi toistaa eikä siten tutkia. Jos syykin on löydetty, yhden bugin korjauksen löytäminen ja testaaminen voi viedä 15 minuutista päiväkausiin.
Bugiraporteissa olevat lisätietokyselyt tulevat nekin yleensä yhteisön jäseniltä, jotka harrastavat tätä kyselyä ja "Triaged":ksi merkitsemistä. Tämä auttaa kehittäjiä näkemään, että "ahaa, tuon nimisessä bugissa _saattaa_ ainakin olla tarpeeksi tietoja varsinaisen ongelman selvittämiseksi". Myös yhtä bugitriagoijaa kohden lienee helposti tuhat bugia, mutta on huomattavasti helpompaa kysellä lisätietoja suht rutiininomaisesti kuin lähteä varsinaisesti selvittämään ongelmaa.
Jos oikeasti haluaa saada jonkin tietyn, lähinnä omaa kokoonpanoa koskevan ongelman korjatuksi, on paras tapa keskittyä siihen miten ongelman korjaamisen tekee mahdollisimman helpoksi esim. paketin ylläpitäjälle. Esimeriksi jokin laiteongelma tietyllä komponentilla, ja havaittuna kiertokeinona esim. kernelin moduulille parametri:
1. Tulee selvittää mihin esimerkiksi laitekomponentin PCI-ID:tä vastaava poikkeussääntö tulee lisätä.
2. Tulee ottaa esim. hal:n/minkälie lähdekoodi (apt-get source hal), tehdä tarvittavat lisäykset ja tehdä bugiraporttiin liitettäväksi testatusti toimiva patchi (esim. diff -urN vanha-versio-hakemisto uusi-paranneltu-versio-hakemisto > mun_patchi.patch)
Tässä on se hankalin osuus tietysti tehty, eli on ylipäänsä löydetty ongelmaan korjaus. Mutta patch ei vielä ole optimaalinen tapa tarjota korjausta, vaan:
3. apt-get source yleensä kertoo, jos paketilla on versionhallinta tietyssä Bazaar-versionhallinnassa. Tulee siis ottaa bzr-työkalulla kyseinen kehitysversio vaikka hal:sta ja tarkistaa toimiiko patch myös siellä.
4. Lisäksi tulee luoda omalle Launchpad-tunnukselle Bazaar-haara (code.launchpad.net / Register Branch) kyseisestä paketista, johon lykkää korjaukset.
5. Tämän jälkeen vielä Merge / Review Request emohaaraan, ja bugiraporttiin viittaus korjauksen sisältävään bzr-haaraan.
(6. Korjauksen mentyä sisään korjauksen lähettäminen varsinaiselle hal-projektille, tai keskustelu Ubuntu-ylläpitäjän kanssa siitä miten korjaus toimitetaan eteenpäin)
Jos tällaiseen tilanteeseen pääsee, että korjattu versio löytyy bzr-versionhallinnasta, niin ongelman korjaus on tehty mahdollisimman helposti käyttöönotettavaksi. Tällainenkin bugiraportti voi kuitenkin mennä niiden tuhansien muiden kommenttien myötä ohitse, joten jos pariin viikkoon ei tapahdu mitään, kannattaa esim. pingata kehittäjää sähköpostitse tai IRCissä korjauksen mukaan ottamisesta.
Tämän pointti oli lähinnä yrittää muistuttaa, että ei edes kannata olettaa (tai pettyä) että tietty bugiraportti pelkällä nopealla raportoinnilla tulee korjatuksi, ellei ongelman teknisesti oikeanlainen korjaus ole ilmoitettu samassa raportissa. Ubuntun (kymmenet?) miljoonat käyttäjät ovat luoneet suhteellisen lyhyessä ajassa yli 300 tuhatta bugiraporttia, joista suurimmassa osassa ns. signaali-kohinasuhde ei ole mikään paras mahdollinen. Tällaisen määrän hallitseminen on yhtä lailla tai enemmän aktiivisten yhteisöjäsenten kuin varsinaisesti palkattujen kehittäjien (n. 100 max.) varassa, etenkin koska moni bugeista on kehittäjän kannalta sen verran epämääräinen ettei sitä kertakaikkiaan pysty tutkimaan esim. ilman juuri samaa laitekokoonpanoa.
Minä tahansa hetkenä on myös tiedossa satoja useaa käyttäjää koskevia bugeja, joita on mielekkäämpää tutkia kun yleensä myös tietoa ongelman aiheuttajasta on enemmän. Ja samaan aikaan pitäisi tehdä myös muuta kuin bugien korjausta, esimerkiksi kehittää seuraavaa Ubuntun julkaisua.
-
Tämän pointti oli lähinnä yrittää muistuttaa, että ei edes kannata olettaa (tai pettyä) että tietty bugiraportti pelkällä nopealla raportoinnilla tulee korjatuksi, ellei ongelman teknisesti oikeanlainen korjaus ole ilmoitettu samassa raportissa.
Hyvä esimerkki on oma bugiraporttini. Melkein vuosi tuosta vierähti ja kaksi julkaisua (Beta 8.04 -> 9.04):
https://bugs.launchpad.net/ubuntu/jaunty/+source/linux/+bug/208137
Tuollainen vuosi ja pari julkaisua voisi olla siis ihan hyvä mitta. kun bugi ei koske kaikkia käyttäjiä kaikilla laitteilla, vaan aika marginaalista ryhmää erikoislaitteella.
Ystävällisin terveisin Asmo Koskinen.
-
https://bugs.launchpad.net/ubuntu/jaunty/+source/linux/+bug/208137
Tähän bugiin tuli juuri yksi kehittäjän kommentti lisää:
* Description changed:
I have HP t5000 thin client. Everything works on Edubuntu 7.10 Classroom
Server.
On Hardy Alternate Beta 8.04 it fails to boot. It flashes green screen
and after that boot itself again.
Just before green screen flash t5000 says this: "memory size detection
failed"
Here is Flash-movie about booting process:
http://www.arkki.info/howto/Wiki/T5000_Hardy_32.flv
There is similar bug filed for MythTV:
"Summary: Both the kernel vt8623fb driver and the Xorg via driver should
be changed to correctly determine the amount of video memory."
https://bugs.launchpad.net/mythbuntu/+bug/179634
Best Regards Asmo Koskinen
+
+ ===
+
+ SRU Justification
+
+ Justification: systems with the vt8623fb driver crash on boot if the
+ vt8623fb driver is loaded
+
+ Impact: system crash
+
+ Fix Description: blacklist the vt8623fb driver in the framebuffer
+ blacklist
+
+ Patch: http://launchpadlibrarian.net/22416917/module-init-tools
+ --blacklist-vt8623fb-framebuffer-intrepid
+
+ Risks: anyone specifically using this driver would have to unblacklist
+ it, we normally blacklist these drivers by default this one is missing
+ from the list
+
+ TEST CASE: see bug description
** Changed in: module-init-tools (Ubuntu Intrepid)
Assignee: (unassigned) => Andy Whitcroft (apw)
Status: New => In Progress
** Changed in: linux (Ubuntu Intrepid)
Assignee: (unassigned) => Andy Whitcroft (apw)
Status: New => In Progress
** Changed in: linux (Ubuntu Intrepid)
Importance: Undecided => Medium
Ystävällisin terveisin Asmo Koskinen.
-
Launchpadissa bugeja käsittelevien rooleista puuttui ainakin vielä ne, jotka vievät bugeja oikeisiin paikkoihin. Ubuntussa toki korjataan ohjelmien bugeja, jos ne ovat merkityksellisiä Ubuntulle, joku muu ei ole niitä vielä korjannut eikä kokonaan uusi, mahdollisen korjauksen sisältävä ohjelmajulkaisu ehdi seuraavaan Ubuntuun, mutta varsinaisestihan kaikki distrot ovat eritoten integrointiprojekteja. Ubuntulla on toki merkittäviä osasia jotka tekevät Ubuntusta juuri Ubuntun, mutta kuten "kaikki" tietävät, kaikki vapaaohjelmistojakelut käyttävät luonnollisesti samaa OpenOfficea, samaa Linux/BSD-ydintä, samaa Gnome/KDE:ta jne. hyvin pitkälle, ja jokin tietty bugi ei yleensä ole vain Ubuntun.
Esim. Linux-kernelissä tai Gnomessa oleva bugi on loppukädessä itse ohjelmaprojektissa, ja jakelu vain käyttää ko. projektin julkaisua ja mahdollisesti (bugeja tarkastelevien toimesta) kertoo käyttäjien löytämistä virheistä ohjelmaprojektille. Linux-kernel on esimerkiksi niin tärkeä osa Ubuntua, että sille on Ubuntussakin/Canonicalilla oma tiiminsä, mutta silti Ubuntu ei varsinaisesti ole se taho joka voi korjata muita kun sen kourallisen bugeja mitä muutama henkilö ehtii kaiken upstream-projektin kanssa käytävän keskustelun, integrointityön, suunnittelun ja testauksen ohessa.
Sitten jos kyse on vaikka jostain OpenOfficesta, niin Debianissa ko. ohjelman paketointia tekee pääasiassa yksi (erittäin pätevä) henkilö vapaa-ajallaan, ja Ubuntun puolella yksi (palkattu) henkilö monen muun toimensa ohella tekee tämän pohjalta Ubuntu-sovitusta.
Ohjelmapalikoita on monta, bugeja korjaillaan yleensä ohjelmaprojekteissa itsessään ja Launchpad on lähinnä erittäin suuri, meluisa joukko bugiraportteja, joissa olisi paljon informaatiota jos vain olisi ihmisiä jotka ehtisivät niitä käydä läpi, jalostaa ja siirtää edelleen oikeille tahoille jne. :) Tähänhän yhteisöä on monin tavoin yritetty rohkaista, ja toisaalta myös yritetty tarjota Launchpadin tietoja helpommin itse ohjelmaprojekteille. Ubuntun käyttäjille Launchpad on toki oikea paikka ilmoittaa virheistä, mutta mitään maagista prosessia ei ole jolla tietty virhe tulisi korjatuksi ilman melko suurta monen ihmisen työpanosta, joko vapaa-ajalla tai työajalla.
-
Ja samaan aikaan pitäisi tehdä myös muuta kuin bugien korjausta, esimerkiksi kehittää seuraavaa Ubuntun julkaisua.
Tässä nimenomaan mielestäni mennään metsään. Paukut eivät riitä bugikorjaukseen, kun nopealla aikataululla pitäis saada jo uutta releasea. Tästä syystä kaikki releaset on vähän sinnepäin ja bugisia. Kierre on valmis.
Olen edelleen sitä mieltä, että 6kk release aikataulu ei ole hyväksi Ubuntulle.
https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/312423
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/308820
https://bugs.launchpad.net/ubuntu/+source/hal/+bug/305339
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/309572
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/307780
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/294317
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/290842
https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/286437
https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/274201
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/269693
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/253225
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/247879
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/247335
Tuossa nyt alkuun... Omalle suspend bugille löytyy siis monta duplikaattia / vastaavaa erroria. Luultavimmin korjaus yhteen saattaisi korjata nämä kaikki. Varmuutta tietenkää ei ole.
Valitettavasti... sellaisessa koneessa, missä tarvin vakautta, en valitse Ubuntua. Tällöin asennan Debianin, niin ainakin tietää että homma toimii. Onneksi on toinen partitio, jossa voi aina kokeilla Ubuntun toimivuutta. Ubuntulle kun kuitenkin on niin paljon pakettivarastoja, se on positiivinen juttu. Helpottaa ku ei tarvi käännellä ite :). Esimerkiksi oma suosikkini on Ubuntu server + LXDE ;)
-
Tässä nimenomaan mielestäni mennään metsään. Paukut eivät riitä bugikorjaukseen, kun nopealla aikataululla pitäis saada jo uutta releasea. Tästä syystä kaikki releaset on vähän sinnepäin ja bugisia. Kierre on valmis.
Olen edelleen sitä mieltä, että 6kk release aikataulu ei ole hyväksi Ubuntulle.
Tuossa voit olla oikeassa, että 6kk on ainakin joskus liian lyhyt aika. LTS-julkaisut ovat periaatteessa niitä hiotumpia, ja kyllä 8.04 LTS onkin aika hyvä - toisaalta sitten kuitenkin pulseaudio varmasti aiheutti ongelmia aika monelle, ja oli se Firefox 3:kin riski vaikkakin hyvistä syistä. Yksi ongelma on kyllä myös, että ihmiset eivät malta pysyä LTS-julkaisuissa :)
Paikalleen ei voi kuitenkaan myös jäädä, koska esim. kun Mozilla lopettaa 2.x-version tuen ja muut ovat siirtyneet 3.x:ään, kertyy vain hyvin paljon lisää ylläpitokuormaa joka toisaalta sitten lisää taas bugisuuttakin. Mutta jossain vaiheessa julkaisusykliä voisi pohtia uusiksi, miten olisi esim. 8kk julkaisutahti niin, että olisi esim. 8.04 LTS, 8.12, 9.08, 10.04 LTS? Saisi pidettyä kuitenkin 2 vuoden LTS-tahdin.
Toinen vaihtoehto on että LTS:ää seuraavan julkaisun voisi melkein vaikka jättää välistä... Ubuntu 8.10 on oikeastaan kyllä aika hyvä, mutta kyllä yleismielikuva on että 6.10 ja 8.10 ovat molemmat saaneet muita julkaisuja vähemmän huomiota, ja bugeja riittää, kun LTS-julkaisun .1-version kehittäminen on jatkunut kesä-heinäkuulle asti. Tämä vaihtoehto toisi sitten syklin 8.04 LTS, 9.04, 9.10, 10.04 LTS.
Suurin ongelma on mielestäni nimenomaan tuossa LTS-julkaisun jälkeisessä ajassa, 6kk siitä seuraavaan julkaisuun on liian vähän, koska LTS:n parissa tehdään muita enemmän työtä myös julkaisun jälkeen. Muiden julkaisujen välissä se 6kk voi olla ok, koska Ubuntu kuitenkaan ei ihan ensimmäisenä ole upouusia ominaisuuksia integroinut, vaan tekee jonkinasteista riskianalyysiä (esim. ei KMS:ää 9.04:ään).
Onneksi on tosiaan Debiankin vaihtoehtona, on valinnanvaraa – Debian, Ubuntu LTS, Ubuntu.
Tuossa nyt alkuun... Omalle suspend bugille löytyy siis monta duplikaattia / vastaavaa erroria. Luultavimmin korjaus yhteen saattaisi korjata nämä kaikki. Varmuutta tietenkää ei ole.
Tuota en kyllä oikein usko, koska suspend-ongelmat ovat erittäin laaja vyyhti. Siinä ei myöskään välttämättä pidempi julkaisusykli auta, jos ongelma on valitulla Linux-ytimellä kyseisen laitteen tuessa (tai tarkemmin ottaen väärin toimivan laitteen kiertokonstin sisällytyksessä). Toki tuonne acpi-support-paketin puolelle voi tällöin pidempään kerätä konekohtaisia kiertokonstiluetteloita, eli jonkin verran tilanne varmasti parantuisi. Yhtään ei kyllä auta se, että moni käyttää suljettuja NVIDIA:n ja AMD:n ajureita, joilla ongelmia on paljon eikä ko. ongelmia voi korjata.
-
Tuota en kyllä oikein usko, koska suspend-ongelmat ovat erittäin laaja vyyhti. Siinä ei myöskään välttämättä pidempi julkaisusykli auta, jos ongelma on valitulla Linux-ytimellä kyseisen laitteen tuessa (tai tarkemmin ottaen väärin toimivan laitteen kiertokonstin sisällytyksessä). Toki tuonne acpi-support-paketin puolelle voi tällöin pidempään kerätä konekohtaisia kiertokonstiluetteloita, eli jonkin verran tilanne varmasti parantuisi. Yhtään ei kyllä auta se, että moni käyttää suljettuja NVIDIA:n ja AMD:n ajureita, joilla ongelmia on paljon eikä ko. ongelmia voi korjata.
Saattaa olla, mutta saattaa myös olla että yksi korjaus korjaisi kaikki bugit. Koskaan ei voi olla varma.. Noissa bugeissa vaa nimittäin on niin laajasti erilaista rautaa, eri kerneleitä, eri valmistajien näyttiksiä, yms.. Sen takia uskon että vika ei ole jossain tietyssä kiertokonsteissa.
Ja omalla raudalla Debian vaa jyllää suspendia mainiosti, kun taas Ubuntussa ei ole toiminut kuin 7.10 versiossa (eikä siinäkään heittämällä vaa muistaakseni piti asentaa uswsusp).
-
Mutta jossain vaiheessa julkaisusykliä voisi pohtia uusiksi, miten olisi esim. 8kk julkaisutahti niin, että olisi esim. 8.04 LTS, 8.12, 9.08, 10.04 LTS? Saisi pidettyä kuitenkin 2 vuoden LTS-tahdin.
Toinen vaihtoehto on että LTS:ää seuraavan julkaisun voisi melkein vaikka jättää välistä... Ubuntu 8.10 on oikeastaan kyllä aika hyvä, mutta kyllä yleismielikuva on että 6.10 ja 8.10 ovat molemmat saaneet muita julkaisuja vähemmän huomiota, ja bugeja riittää, kun LTS-julkaisun .1-version kehittäminen on jatkunut kesä-heinäkuulle asti.
Kumpikin vaihtoehto on ongelmallinen. 6kk sykli sopii hyvin yhteen Gnomen julkaisujen kanssa. Yhden version jättäminen välistä taas rikkoisi ikävästi julkaisujen tasaisuuden. Käyttäjä voi tietysti jättää LTS versiota (8.04) seuraavan version (8.10) päivittämättä ja vaikka asentaa sitä seuraavan (9.04) uutena asennuksena.
-
Ja omalla raudalla Debian vaa jyllää suspendia mainiosti, kun taas Ubuntussa ei ole toiminut kuin 7.10 versiossa (eikä siinäkään heittämällä vaa muistaakseni piti asentaa uswsusp).
Tuo olisi hyvä tieto lisättäväksi bugiraporttiin. En uskalla suositella Debianin kernelin kokeilua Ubuntussa, kun en tiedä rikkooko se jotain. Kernelin kääntäminen voisi olla parempi ratkaisu.
Debian on myös laadukas jakelu :)
-
Saattaa olla, mutta saattaa myös olla että yksi korjaus korjaisi kaikki bugit. Koskaan ei voi olla varma.. Noissa bugeissa vaa nimittäin on niin laajasti erilaista rautaa, eri kerneleitä, eri valmistajien näyttiksiä, yms.. Sen takia uskon että vika ei ole jossain tietyssä kiertokonsteissa.
Kärjistetysti koko ACPI-virranhallintastandardi on yhtä kuin kiertokonstien suuri kasa, ja suunnittelultaan susi. Jos noin suuren laitteistomäärän ongelmiin olisi olemassa yksi selkeä ratkaisu, se olisi jo toteutettu. Jokainen noista bugeista voi todellisuudessa olla bugi aivan eri paikassa. Suspend ei ole mikään yksi "teepä suspend", vaan vaatii koko laitteiston ja ajureiden saumattoman yhteistyön tilan tallentamisessa ja komponenttien siirtämisessä toiseen tilaan oikeassa järjestyksessä, sekä jälleen laitteiston käynnistäminen oikealla tavalla. Vika yhdessäkin kohdassa rikkoo ns. kaiken, niitä kohtia on tosiaan monta ja laitekokoonpanomahdollisuuksia tuhansia.
Useimmat suspend-bugiraportit Launchpadissa eivät kerro itse ongelmasta paljon, koska suspend-ongelmien jäljittäminen on usein hankalaa Linux-ytimen kehittäjillekin - miten saat tietoa irti koneesta, jonka toiminta on jo suurimmalta osin keskeytetty ja jokin on vieläpä mennyt vikaan? Siinä ei auta vaikka osaa kertoa laitekomponentit, dmesg:n ynnä muuta perustietoa.
Noissa linkatuissa bugiraporteissakin useissa esiintyy nvidian suljettu näytönohjainajuri, jonka edessä käytännössä sekä Ubuntun että Linux-ytimen kehittäjät nostavat kädet pystyyn. Käyttäjän kannalta ongelma on toki Ubuntussa tällöinkin, mutta teknisesti asialle ei voi tehdä mitään (paitsi tietysti nvidia itse). Osassa bugiraporteissa kerrotaan vain ongelman oireet ("musta ruutu, kursori vilkkuu"), jotka taas eivät auta ongelman ratkaisussa mitenkään. Ja tosiaan ikävä kyllä ne hyvätkin bugiraportit tuolla, jos eivät liity selkeästi johonkin Ubuntun tekemään muutokseen, ovat oikeastaan väärässä paikassa koska oikea sijainti olisi http://bugzilla.kernel.org/. Mutta yksi Launchpadin tarkoitusperistä onkin toimia bugiraporttien sulatusuunina, josta toivottavasti valuu se todella konkreettinen, tekninen tieto eteenpäin.
-
Edelleen Timo pidät hienosti Ubuntun puolia.. :)
Se mikä Ubuntussa ei toimi, niin toimii kuitenkin Debianissa. Jotain siis Ubuntussa on tehty eri lailla ja siinä luultavimmin syy. Tiedän kyllä että acpi on surkuhupaisasti suunniteltu viritelmä.. Mutta toisaalta; miksi Debianissa suspend toimii (Etch, Lenny, etc..), mutta Ubuntussa ei toimi (Gutsy, Hardy, Intrepid, etc..)? Täysin sama laitteisto.. Jotain siis Ubuntussa on viritelty ja niiden raportointi ei kuulu bugzilla.kernel.org:iin.
Senkin voin kertoa, että käytän nvidian suljettua ajuria.. mutta edelleen, kaikilla nvidian eri ajuriversioilla Debian vaa pelittää (1.0-96xx, 100.14.xx, 169.xx, 17x.xx, 18x.xx), mutta Ubu ei.. siis aatellen suspendia.
-
Edelleen Timo pidät hienosti Ubuntun puolia.. :)
:) Yritän vain pitää kokonaiskuvan mukana, ongelmia kun on monentyyppisiä eikä tosiaan vain yhdestä asiasta johtuvia. Ja sitten vielä se että Launchpad-bugitulva on niin suuri, että ei kellään (paitsi koko yhteisöllä) ole resursseilla yrittää käydä niitä läpi.
Se mikä Ubuntussa ei toimi, niin toimii kuitenkin Debianissa. Jotain siis Ubuntussa on tehty eri lailla ja siinä luultavimmin syy. Tiedän kyllä että acpi on surkuhupaisasti suunniteltu viritelmä.. Mutta toisaalta; miksi Debianissa suspend toimii (Etch, Lenny, etc..), mutta Ubuntussa ei toimi (Gutsy, Hardy, Intrepid, etc..)? Täysin sama laitteisto.. Jotain siis Ubuntussa on viritelty ja niiden raportointi ei kuulu bugzilla.kernel.org:iin.
Tuossa on aika hyvä lähtökohta kyllä tehdä tarkempaa tutkimusta, ja asia jonka bugiraportissakin mainitsemalla saattaa tehdä bugista monia muita kiinnostavamman (koska tosiaan ei välttämättä ole kernel-bugi suoraan). Onko yhdessäkään Debianissa sama kernelin pääversio (2.6.24 esim.) kuin kokeilemassasi Ubuntussa? Esim. etchiin saa sen "etch and a half" -kernelin joka on 2.6.24. Ei kuitenkaan voi jättää huomioimatta, että ongelma esiintyisi esim. 2.6.24:ssa (hardy), ei 2.6.26:ssa (lenny), ja taas 2.6.27/2.6.28:ssa (intrepid/jaunty). Näitä selvittäessä ongelman haarukointi on aina hyväksi. Ja tosiaan tuo Debian-pointti kannattaa mainita siellä bugin kuvauksessa, mutta mielellään vasta sitten kun on kokeiltu Debian/Ubuntua joissa sama kernel (esim. se Debian etch-and-a-half 2.6.24:lla ja Ubuntu 8.04 LTS). Siitä voitaisiin päästä kernelin ulkopuolelle, mikä on sentään edistystä.
Vielä se kyllä pitää mainita, että kannattaa kokeilla nvidia-ajurin poistamista ja nv-ajurin käyttöä suspend-testailuihin. Kuten jo todettu, se mahdollisuus että lopulta ongelma jollain tavalla liittyisi suljettuun ajuriin laskee jo bugiraportin kiinnostavuutta. Ja tästä tulikin mieleen, että Debian lennyssäkään _ei_ ole 1.5.0-Xserveriä kuten Ubuntu 8.10:ssa, vaan 1.4.3. Ja melko tunnettu fakta on, että NVIDIAn ajurit hajoilevat jatkuvasti jokaisen uuden X:n ilmestyessä, ja usein eritoten suspend-ongelmia esiintyy. Ja joka tapauksessa tuo onko ongelmaa nv-ajuria käyttämällä (nvidia kokonaan poistettuna) on jälleen yksi lisätieto bugiraporttiin.
Kohtapuoliin Debian 5.0 julkaistaan, ja unstableen mennee 2.6.28. Tällöin olisi hyvä mahdollisuus vertailla Debian sidiä (tai lennyä sidin kernelillä) ja Ubuntun jauntyä rinnakkain. Tuossa on sekin mielenkiintoinen juttu, että Ubuntu kun perustuu Debianiin, niin se on melko yhdenmukainen muiltakin osin (acpi-support-paketti jne.) Debianin kanssa. Mutta tosiaan tuo X-server menee tällä hetkellä eri versionumeroissa, paitsi jos vertailee Ubuntu 8.04 & Debian 5.0.
Itse viestiketjun aiheeseen liittyen esimerkkisi (suspend-ongelma) näyttää bugikorjauksen ja -raportoinnin hankalimmat puolet - noita on niin vaikea debugata että tarvitsisi olla itse lähes kernel-kehittäjä osatakseen jäljittää virhettä riittävän pitkälle, jotta tietojen avulla ongelma voitaisiin korjata.
Muistaakseni nyt 9.04:ssa kävi käsky Canonicalilta, että käyvät läpi jokaisen työntekijän kaikki koneet, etsivät onko suspend-ongelmia ja korjaavat. Yksi tapa lähestyä ongelmaa :) Tosin esim. nvidiallisia koneita ei varmaan lasketa mukaan. Toki myös esim. Dell varmistelee omia koneitaan ja muutenkin yhteisön lisäksi myös yritysapureita on. Nyt julkaisuun keskityttäessä on kuitenkin jo valittu kernel (2.6.28), niin ei voida enää odottaa maagisesti paremmin toimivaa kerneliä Torvaldsin suunnalta, vaan pitää hioa tätä ympärillä olevaa. Ubuntu 8.10:n kanssa muuten otettiin harppaus 2.6.27:een suht viime metreillä, varmaan sekin on vaikuttanut suspendin hajoiluun.
Senkin voin kertoa, että käytän nvidian suljettua ajuria.. mutta edelleen, kaikilla nvidian eri ajuriversioilla Debian vaa pelittää (1.0-96xx, 100.14.xx, 169.xx, 17x.xx, 18x.xx), mutta Ubu ei.. siis aatellen suspendia.
Ok, tuokin on hyvä tieto.
-
Ja tosiaan tuo Debian-pointti kannattaa mainita siellä bugin kuvauksessa, mutta mielellään vasta sitten kun on kokeiltu Debian/Ubuntua joissa sama kernel (esim. se Debian etch-and-a-half 2.6.24:lla ja Ubuntu 8.04 LTS).
Debianissa on kokeiltu 2.6.24 toimivasti, Ubuntussa ei toimivasti.
Vielä se kyllä pitää mainita, että kannattaa kokeilla nvidia-ajurin poistamista ja nv-ajurin käyttöä suspend-testailuihin.
Ubuntussa on kokeiltu ilman binääriajureitakin.. ja lopputulos ei vaa toimi.
Edited: Sen lisään tähän viel, että mulla on siis usko mennyt tuohon Launchpadiin... Ei sinne jaksa noitakaa infoja alkaa lisäilemään, sillä se on turhaa. Vastaukset bugeihin tulee kuukausia myöhässä, jolloin uusi versio on jo ulkona. Tällöinkin käsketään yleisemmin vain testailemaan sillä sitten.
-
Edited: Sen lisään tähän viel, että mulla on siis usko mennyt tuohon Launchpadiin... Ei sinne jaksa noitakaa infoja alkaa lisäilemään, sillä se on turhaa. Vastaukset bugeihin tulee kuukausia myöhässä, jolloin uusi versio on jo ulkona. Tällöinkin käsketään yleisemmin vain testailemaan sillä sitten.
Ok no sitten asian pidempi tutkiminen ei ole kovin hyödyllistä.
Edelleen ehkä hieman häiritsee tuo asenne siitä että "vastaukset bugeihin tulee myöhässä" - kenen niitä vastauksia pitäisi tehtailla, ja mitä niiden vastauksien pitäisi sisältää? Sekin joka bugiraporttiisi vastasi jauntyn kokeilemisesta näyttäisi olevan satoja bugeja vapaa-ajallaan käsittelevä henkilö. Kuinka paljon lisää aikaa juuri hänen pitäisi lisää käyttää tutkiakseen sinun ongelmaa? Ja mitä kukaan voi tehdä jos hänellä ei ole samaa HP:n konetta kuin sinulla? Annetuissa tiedoissa syötelaitteista voi olla sopivalle asiantuntijalle tiedonjyvänen mahdollisesta ongelman aiheuttajasta, mutta voi olla myös että nykyisillä bugiraportissa olevilla tiedoilla ei kukaan ongelmaa voi vielä jäljittää (esim. toinen kone samoilla tiedoilla toimii moitteetta). Jälkimmäisessä tapauksessa kukaan ei edes voi vastata bugiraporttiin muuta kuin että "kokeilepa jauntyllä", ellei sitten "kokeile synaptics-ajurin git-versiota debug-outputilla, ja vertaa toisaalle".
Jos ainoa ongelma on tuo näppäimistön toimimattomuus, eli kannettavaan sisältyvät syötelaitteet eivät toimi, luulisin että ongelma ei ole kernelissä vaan esim. X:ssä. Ja tällainen ongelma on tosiaan täysin eri suspend-ongelma kuin ne yleiset, eli että laite ei herää suspendista lainkaan.
Jos tämän tutkimisessa haluaisi edetä, mitä nyt ei ilmeisesti haluttu, olisi hyvä etsiä esim. tuon synapticsia käyttävän laitteen vendor/product-tiedoilla mahdollisia kohtalotovereita, merkitä jokin bugi toisen duplikaatiksi jos vastaava oire (näppäimistö/touchpad ei toimi suspendin jälkeen) löytyy ja jatkaa sitä kautta. Mitä paremmin jokin tietty ongelma saadaan eristettyä ja kerättyä samat bugit toistensa duplikaateiksi, sitä paremmin ongelma alkaa hahmottua ja ylipäänsä erottua Launchpadin tuhansien "bugiraporttien" kohinasta. Myös joku toinen voi jossain vaiheessa lähteä tätä tutkimustyötä tekemään, esim. tämä joka jauntyn kokeilemista ehdotti, mutta kyse on siitä löytyykö ihmisiä, esim. näiltä foorumeilta, jotka tuota työtä voisivat tehdä. Niillä kehittäjillä, jotka osaisivat mahdollisesti tällaisen ongelman korjata, ei ole aikaa käydä henkilökohtaista keskustelua jokaisen tuhansista bugiraportoijista kanssa vain sen takia, että ongelman jäljittämiseen tarvittavia tietoja ole.
Suomen / tämän foorumin tasolla omia bugiselvittelyitä / kiinnostavia bugeja voi listata esim. Ubuntun kehittäminen (http://wiki.ubuntu-fi.org/Ubuntun_kehittaminen) -sivulle, esim. jos haluaa ottaa pieneksi urakakseen suspend-ongelmiin liittyvien bugien työstämisen/jalostamisen. Ja tämä on nyt suunnattu niille, joilla olisi halua käyttää vapaa-aikaansa bugien jäljittämis/korjailupuuhiin (se on ihan mukavaa puuhaa saada "järjesteltyä"/keräiltyä bugeja, jopa ratkaistua, ja autettua ihmisiä jotka ovat bugiraportteja laittaneet).
Vaihtoehtona Launchpadille olisi toki normaali ohjelmatoimittajan tapa, eli ei bugienraportoimisjärjestelmää lainkaan. Avointen ohjelmaprojektien puolella tapana ei vain ole ongelmia peitellä, mutta ongelmien ratkaisu on myös kaikkien ongelmien ratkaisemisesta kiinnostuneiden harteilla kollektiivisesti.
Edit: Lisäyksenä yhteenveto: "a) mikään softa ei ole bugitonta, b) kukaan ei voi korjata kaikkia bugeja, c) avoimissa softissa yhteisöstä kokonaisuutena, mukaan lukien mahdolliset palkatut työntekijät yrityksissä, on kiinni, mitkä bugit tulee korjatuksi". Eli tarkoituksenani ei ole sanoa etteikö Launchpad toimi käyttäjän kannalta epäoptimaalisesti, ja olisi mukava jos palautetta tulisi enemmän sekä toimintaa, vaan tuoda nuo kolme pääpointtia vain esiin.
-
Edelleen ehkä hieman häiritsee tuo asenne siitä että "vastaukset bugeihin tulee myöhässä" - kenen niitä vastauksia pitäisi tehtailla, ja mitä niiden vastauksien pitäisi sisältää? Sekin joka bugiraporttiisi vastasi jauntyn kokeilemisesta näyttäisi olevan satoja bugeja vapaa-ajallaan käsittelevä henkilö. Kuinka paljon lisää aikaa juuri hänen pitäisi lisää käyttää tutkiakseen sinun ongelmaa?
Et ymmärrä nyt minun pointtiani. Bugikorjaukseen ei ole Ubuntulla paukkuja, kun ei ole vain yksinkertaisesti aikaa ku seuraava release painaa päälle. Tätä yritän tässä toitottaa... Kun ei ehditä bugeja korjailla, niin kaikki releaset ovat bugisia ja kierre on valmis. En ole ainut joka ajattelee näin...
Jos ainoa ongelma on tuo näppäimistön toimimattomuus, eli kannettavaan sisältyvät syötelaitteet eivät toimi, luulisin että ongelma ei ole kernelissä vaan esim. X:ssä. Ja tällainen ongelma on tosiaan täysin eri suspend-ongelma kuin ne yleiset, eli että laite ei herää suspendista lainkaan.
Nyt epähuomiossa olen puhunut väärin. Eli tämä bugi mistä nyt puhut, ei ole se mistä itse puhun. En ollutkaan avannut itse bugia, vaan täydentänyt erään toisen avaamaa bugia. Sori sekaannus siitä...
Se bugi mitä ajan takaa on, kun Ubuntu ei edes mene suspend-tilaan. Kovalevy sammuu, fanit jää pyörimään, näyttöön jää vain vilkuttava underscore, jne... Vain reboot auttaa. Ja noita bugeja on pilvin pimein launchpadissa... Eikä kommentin kommenttia liitteiden lisäämisien jälkeen missään bugissa. Suspend on kuitenkin prioriteetiltaan minusta aika oleellinen asia, niin luulisi että niitä edes jotenkin tsekattaisiin.
Mutta edelleen kaikki kaatuu minusta siihen, että ei vaa ole aikaa niitä tsekata (uus release painaa päälle). Tämä on minun pointtini ja siksi olen ottanut sen asenteen, että en itse sinne Launchpadiin mitään laita, ku ei sillä ole vaikutusta. Kyllä osaan ihan itsekin aina kokeilla uudella releasella, enkä vain jonkun kehotteesta.
Itse olen yrittänyt myös metsästää vikaa, mutta tietotaito ei vaa riitä. Joten helpompaa aina pitää Debian yhdellä partitiolla ja kokeilla Ubuntua silloin tällöin, josko jokin versio toimisi. Niin kun sanoin, niin Ubuntua haluaisin käyttää lähinnä siksi että pakettivarastoja on pilvin pimein. Helpottaa ettei tarvi ite käännellä ku välillä kääntelyssä tulee mutkia matkaan...
-
Jos tämän tutkimisessa haluaisi edetä, mitä nyt ei ilmeisesti haluttu, olisi hyvä etsiä esim. tuon synapticsia käyttävän laitteen vendor/product-tiedoilla mahdollisia kohtalotovereita, merkitä jokin bugi toisen duplikaatiksi jos vastaava oire (näppäimistö/touchpad ei toimi suspendin jälkeen) löytyy ja jatkaa sitä kautta. Mitä paremmin jokin tietty ongelma saadaan eristettyä ja kerättyä samat bugit toistensa duplikaateiksi, sitä paremmin ongelma alkaa hahmottua ja ylipäänsä erottua Launchpadin tuhansien "bugiraporttien" kohinasta.
No en minä kyllä noinkaan ole sanonut, että en haluaisi edetä tuon tutkimisessa, vaan kun en viitsisi edes yrittää merkitä bugiraportissani mainittua käytännössä täysin identtistä bugiraporttia duplikaatiksi ja nimenomaan lisäsin tuohon raporttiin linkitetyn bugiraportin tietoja joita oli kysytty myöhemmin, mutta niitä ei oltu saatu.
Oikeastaan nyt päästiinkin asian ytimeen ja ehkä selittää myös alkuperäistä kysymystäni. Eli sain jatkokysymyksen, testasin ja vastasin. Silloin muuttui tila "triaged", enkä siis keksinyt että millä perusteilla näin siis tapahtui ja mitä se tarkemmin käytännöntasolla edes tarkoittaa. Tuskin se triaged statukseen muuttunut sen takia, että jauntyn alpha 3:lla koneeni ei nouse enää lainkaan suspendista? :D
Hiukan OT, mutta toimiiko tuo suspend ylipäätään oikein monilla kannettavilla ihan asennuksen jälkeen. En ole vielä kovin moneen läppäriin kerennyt linuxeja asentaa, mutta jotenkin mutulla taitaa olla todella ongelmallinen linuxeissa? Mitä vanhat linux konkarit tähän sanovat?
*muoks*
läppäreissä en muuten oikeastaan olekaan kokeillut kuin Ubuntuja poislukien eee.
-
Et ymmärrä nyt minun pointtiani. Bugikorjaukseen ei ole Ubuntulla paukkuja, kun ei ole vain yksinkertaisesti aikaa ku seuraava release painaa päälle. Tätä yritän tässä toitottaa... Kun ei ehditä bugeja korjailla, niin kaikki releaset ovat bugisia ja kierre on valmis. En ole ainut joka ajattelee näin...
Timo ei ymmärrä, hmm... ;)
Kenellä on paukkuja? IBM? Sun? RedHat? Novell? Oracle? Öhh... Microsoft?
Linux-kerneliä syytetään aika ajoin ahneudesta lisätä uusia ominaisuuksia, vaikka vanhojakaan ei ole vielä korjattu.
Tämä ketju/vuodatus on vuodelta 2001!!!
"I've used Linux for over 5 years now. In all the time I've used it, I
have never seen this much instability in a single kernel
series - though I've noticed each successive 'stable' series having
more bugs than the last (2.2.x crashed once a week with SMP
until 2.2.10!).
[--]
This brings me to the subject of this rant: are we going too fast? New
drivers are still showing up in each successive kernel, and yet no one
seems to be able to fix the old bugs that already exist."
http://lkml.indiana.edu/hypermail/linux/kernel/0108.1/0881.html
Joten olet huomannut ongelman, joka on ollut olemassa siitä asti, kun ylipäänsä keksittiin ohjelmoida tietokoneita/ohjelmia.
Mitä Alan Cox vastasi vuonna 2001, tuohon valituksen. Samasta "mulle-kaikki-heti-nyt" -ongelmasta ("latest version" obsession) me edelleen kärsimme.
"Kernel.org certainly should list the 2.2 status (hey I maintain it I'm
allowed to be biased). Its unfortunate it many ways that people are still so
programmed to the "latest version" obsession of the proprietary world some
times. For most people 2.4 is the right choice but for absolute stability
why change 8) "
----
Mitä Sinä voit tehdä?
Kirjoittaa kärsivällisesti bugiraportteja ja odottaa. Jos osaat koodata, niin... Use The Source, Luke!
Ystävällisin terveisin Asmo Koskinen.
-
Et ymmärrä nyt minun pointtiani. Bugikorjaukseen ei ole Ubuntulla paukkuja, kun ei ole vain yksinkertaisesti aikaa ku seuraava release painaa päälle. Tätä yritän tässä toitottaa... Kun ei ehditä bugeja korjailla, niin kaikki releaset ovat bugisia ja kierre on valmis. En ole ainut joka ajattelee näin...
Timo ei ymärrä, hmm... ;)
Kenellä on paukkuja? IBM? Sun? RedHat? Novell? Oracle? Öhh... Microsoft?
Linux-kerneliä syytetään aika ajoin ahneudesta lisätä uusia ominaisuuksia, vaikka vanhojakaan ei ole vielä korjattu.
Debianilla tuntuu paukkuja olevan ku aina toimii... Ubuntussa ei ole toiminut kuin 7.10 versiossa vasta asennettuani uswsusp-paketin. Kernelissä se vika ei ole ku Debian käyttää ihan yhtälailla samoja kerneleitä (esmes 2.6.24). On ollut muitakin koneita kuin omani jossa Ubuntun suspend ei toimi, mutta yllättäen Debian vain rokkaa.
En ymmärrä miksi pitää hirveästi pitää puolia jos selkeästi eri distroissa samoilla kerneleillä toinen toimii ja toinen ei. Ja minusta juurikin syypää Ubuntun toimimattomuuteen on liian nopea releasointi aikataulu.
Testasin muuten omassa koneessani Jauntynkin --> ei toiminut. Odotan innolla, että Jaunty nappais tuon 2.6.29 kernelin, josko sillä toimis ku kerneliinkin on tehty jotain muutoksia suspendiin.
-
En ymmärrä miksi pitää hirveästi pitää puolia jos selkeästi eri distroissa samoilla kerneleillä toinen toimii ja toinen ei. Ja minusta juurikin syypää Ubuntun toimimattomuuteen on liian nopea releasointi aikataulu.
En provosoi, vaan sanon, minkä olen ennenkin sanonut.
Äänestä jaloillasi.
Jos Debian tai joku muu distro toimii paremmin, niin käytä ihmeessa sitä.
Minäkin lopetan Ubuntun käytön heti sinä päivänä, kun löytyy parempi distro, joka vastaa minun vaatimuksiani LTSP5:n suhteen. Vielä sellaista distroa ei ole tullut vastaan.
Joten äänestä kukkarollasi, kun kysessä on rauta ja äänestä jaloillasi, kun kysessää on softa. Ei se sen kummempaa ole.
Ystävällisin terveisin Asmo Koskinen.
-
Niin kun sanoin, niin Ubuntua haluaisin käyttää lähinnä siksi että pakettivarastoja on pilvin pimein. Helpottaa ettei tarvi ite käännellä ku välillä kääntelyssä tulee mutkia matkaan...
Tuo on syy miksi Ubuntua yritän koneelleni saada..
-
No en minä kyllä noinkaan ole sanonut, että en haluaisi edetä tuon tutkimisessa, vaan kun en viitsisi edes yrittää merkitä bugiraportissani mainittua käytännössä täysin identtistä bugiraporttia duplikaatiksi ja nimenomaan lisäsin tuohon raporttiin linkitetyn bugiraportin tietoja joita oli kysytty myöhemmin, mutta niitä ei oltu saatu.
Viittasin timballe, mutta eihän se ollutkaan hänen bugiraporttinsa ja sekoitin itsekin nuo lukuisat :)
Ja siis yleensäkin "ok", sain jo sanottua haluamani joten tosiaan:
Tätä yritän tässä toitottaa... Kun ei ehditä bugeja korjailla, niin kaikki releaset ovat bugisia ja kierre on valmis. En ole ainut joka ajattelee näin...
Joo, tästähän olikin jo puhetta, että on varmasti paljon puoltamassa sitäkin että joskus ei enää olisi puolivuosittaisia julkaisuja. Linus itsehän veikkaili vuoden sykliä hyväksi. Toisaalta sitten Ubuntu-käyttäjiä valuisi esim. Fedoran puolelle, ja lisäisikö vai vähentäisikö se sitten yhteisön osallistumista bugien korjailuun jos uutta julkaisua (ja esim. sen alpha/beta-vaiheita) pitäisi odottaa niin kauan. Vaikeita kysymyksiä.
Suspend on kuitenkin prioriteetiltaan minusta aika oleellinen asia, niin luulisi että niitä edes jotenkin tsekattaisiin.
Koko ajan, ja tuhansia bugiraportteja on varmasti käsitelty ja tullut korjatuksi. Ubuntu 9.04:aan on jälleen tarkoitus keskittyä kovasti suspend/resume-ongelmiin, ja tämä voi olla mielenkiintoista luettavaa:
http://blog.redvoodoo.org/2009/02/jaunty-kernel-bits.html
Siellä perustellaan muun muassa, miksi pysyä 2.6.28:ssa 9.04:ää varten, eli voidaan testata paremmin. "We are making the suspend & resume one of our top priorities for this cycle. We ran a suspend and resume workshop with every notebook at the sprint.". 12 koneella testatusta 65:stä heidän sprintissään oli ongelmia, ja niistä 12:sta suurin osa ongelmaisista liittyi NVIDIAn käyttöön. Tulossa on myös yhteisön aktivoimista / organisoimista ongelmien korjaamiseen.
Oikeastaan nyt päästiinkin asian ytimeen ja ehkä selittää myös alkuperäistä kysymystäni. Eli sain jatkokysymyksen, testasin ja vastasin. Silloin muuttui tila "triaged", enkä siis keksinyt että millä perusteilla näin siis tapahtui ja mitä se tarkemmin käytännöntasolla edes tarkoittaa. Tuskin se triaged statukseen muuttunut sen takia, että jauntyn alpha 3:lla koneeni ei nouse enää lainkaan suspendista? :D
Jaa-a :) Se tarkoittaa että bugiin on saatu oleellisia tietoja bugia käsitelleen arvion mielestä, käytännössä varmaan tuo että tiedetään input-laitteista valmistaja/tuote-id:t riittää ainakin siihen että joku kiinnostunut voi tosiaan etsiä yhtymäkohtia muihin ongelmiin, tai jopa synaptics-ajurista mahdollista viitettä juuri tuohon laitteeseen.
Hiukan OT, mutta toimiiko tuo suspend ylipäätään oikein monilla kannettavilla ihan asennuksen jälkeen. En ole vielä kovin moneen läppäriin kerennyt linuxeja asentaa, mutta jotenkin mutulla taitaa olla todella ongelmallinen linuxeissa? Mitä vanhat linux konkarit tähän sanovat?
Tilanne elää aika paljon, mutta kuten yleensä ainakin uusimmilla laitteilla on aina uusia ongelmia. Mutu-tuntumalla vähintään puolen vuoden vanhaan laitteeseen (tai vanhempaan) jos laittaa nykyään tuoreen Linuxin, eikä käytössä ole Nvidiaa, mahdollisuudet ovat varsin hyvät. Tuosta ylempää laskien arviolta 90% :) Mutta paljonhan on upouusia koneita upouusilla emolevyillä, ja sitä nvidiaa myös. Ja myös ATI-käyttäjät usein vielä asentavat suljetun ajurin jolla on ollut tapana hajoilla suspendissa ainakin 7.10:een asti, en tiedä olisiko nyt sattumalta muuttunut luotettavammaksi.
Debianilla tuntuu paukkuja olevan ku aina toimii... Ubuntussa ei ole toiminut kuin 7.10 versiossa vasta asennettuani uswsusp-paketin. Kernelissä se vika ei ole ku Debian käyttää ihan yhtälailla samoja kerneleitä (esmes 2.6.24). On ollut muitakin koneita kuin omani jossa Ubuntun suspend ei toimi, mutta yllättäen Debian vain rokkaa.
Debian on kokonaan yhteisön tekemä distro, eli heillä ei ole Canonicalinkaan tapaista yritystä auttamassa. Tästä voidaan päätellä ainakin se, että jos Ubuntun yhteisö kehittyisi pidemmälle, saataisiin useampia ongelmia ratkaistua. Ja toisaalta toki se, että Debianin pidempi julkaisusykli tuottaa vakaampia julkaisuja.
Ja onneksi on Debian! Kaikki distrot palvelevat erilaisia tarkoituksia, ja Debian on luultavasti "rock solid" -sarjan ykkönen. Ei ole tarkoituksenani pitää ketään Ubuntussa eikä siltä kannalta "puolustaa" Ubuntua, vaan kertoa miten asiat toimivat (tai eivät toimi). Jos Debian toimii paremmin, en voi kuvitella parempaa vaihtoehtoa Ubuntulle, joka suurimmalta osalta on sama asia kuin Debian muutenkin. Jos taas haluaa uudempia ohjelmistoja, on aina jonkin verran enemmän bugejakin. Itse olen pitkään käytänyt Debiania pääkäyttiksenäni työkäytössä.
Niin kun sanoin, niin Ubuntua haluaisin käyttää lähinnä siksi että pakettivarastoja on pilvin pimein. Helpottaa ettei tarvi ite käännellä ku välillä kääntelyssä tulee mutkia matkaan...
Tiedätkö http://www.backports.org/ , http://debian-multimedia.org/ , http://debian-unofficial.org/ , http://www.apt-get.org/ ?
-
Ubuntu 9.04:aan on jälleen tarkoitus keskittyä kovasti suspend/resume-ongelmiin, ja tämä voi olla mielenkiintoista luettavaa:
http://blog.redvoodoo.org/2009/02/jaunty-kernel-bits.html
Kannattaa lukea. Tuolta löytyy mm. pakettivarasto, missä on kokeiltavaksi vanilla kerneleitä, Ubuntussa olevat versiot ilman ubuntun muutoksia ja tuorein kehitysversio (nyt 2.6.29-rc4)
Saisiko ongelmia rajattua ajamalla komennon suspend esim. recovery modessa?
-
Ubuntu 9.04:aan on jälleen tarkoitus keskittyä kovasti suspend/resume-ongelmiin, ja tämä voi olla mielenkiintoista luettavaa:
http://blog.redvoodoo.org/2009/02/jaunty-kernel-bits.html
Kannattaa lukea. Tuolta löytyy mm. pakettivarasto, missä on kokeiltavaksi vanilla kerneleitä, Ubuntussa olevat versiot ilman ubuntun muutoksia ja tuorein kehitysversio (nyt 2.6.29-rc4)
Saisiko ongelmia rajattua ajamalla komennon suspend esim. recovery modessa?
Se on kyllä erinomaista, että Ubuntussa nyt aletaan panostaa tuohon suspendiin. Pitääpä kokeilla noilla 2.6.29 kerneleillä ja noita suspend testiscriptejä. Katotaan kuinka äijän käy.
-
Kannattaa lukea. Tuolta löytyy mm. pakettivarasto, missä on kokeiltavaksi vanilla kerneleitä, Ubuntussa olevat versiot ilman ubuntun muutoksia ja tuorein kehitysversio (nyt 2.6.29-rc4)
Eipä auttanut noikaan.. Vika ei siis ole kernelissä, vaa jossain ihan muualla: Ubuntun virittämissä pm-suspendin quirkseissä, acpin scripteissä, tai jossain muussa vastaavassa virityksessä..
Saisiko ongelmia rajattua ajamalla komennon suspend esim. recovery modessa?
Eipä auta oikein tuokaa.. pm-suspend ku tekee recoveryssa, niin ei mitää muuta tapahu kuin underscore jää vilkkumaan ylänurkkaan. Jotain on kuitenkin Jauntyssä tehty erilailla sillä X:stä suspendatessa näyttö sammuu, mutta suspend moodiin se ei mene kuitenkaan ollenkaa. Kovalevyn vaihdoin hiljaisempaan, niin en ole varma enää sammuuko se niin kuin Intrepidissä.