Jak mądrze zgłaszać błędy

[dziadu]

Zbyt długo siedzę na tym forum, żeby nie wiedzieć jakie błędy popełniają początkujący a często i zaawansowani (chociażby stażem) użytkownicy forum oraz Gentoo. Błędy, które najczęściej wynikają z braku wiedzy, nieprzemyślenia problemu lub tak zwanej, zwykłej ludzkiej głupoty (daleki jestem od twierdzenia, że te osoby są głupie, po prostu nie zawsze korzystają w efektywny sposób ze swoich zasobów). Wydaje mi się, że mam na tyle duże doświadczenie, że jestem w stanie udzielić kilku dobrych rad, jak sobie poradzić z problemem lub jak szukać rozwiązania problemu. 95% problemów jakie mam w systemie potrafię naprawić sam bez pomocy forum, bugzilli lub wyszukiwarki. Mam duże doświadczenie w działaniu systemu, programowaniu, szukaniu dziur w całym i postaram się część tej wiedzy przekazać tutaj. Resztę błędów naprawiam po przeszukaniu zasobów internetu. Problemy najtrudniejsze do rozwiązania to problemy użytkowe, w szczególności nowych aplikacji. I te też najtrudniej wsadzić w pewien szablon postępowania, dlatego też skupię się przede wszystkim na błędach związanych z instalacją programów.

Mam błąd i co mam teraz zrobić
Przede wszystkim nie panikować. Ważna też jest umiejętność czytania raportów o błędzie.

Czemu "error" to nie zawsze błąd
Niestety słowo error stało się przekleństwem, a gdy jest do tego pisane wielką literą to już koniec świata. Na forum znajdzie się wiele wątków z problemami, w których znajdzie się w pierwszym poście raport taki jak ten (i tylko tyle):

Code: Select all

 * ERROR: app-misc/realpath-1.15 failed: 
 *   emake failed 
 * 
 * Call stack: 
 *     ebuild.sh, line  54:  Called src_compile 
 *   environment, line 2248:  Called die 
 * The specific snippet of code: 
 *       emake VERSION="${PV}" SUBDIRS="src man $(use nls && echo po)" || die "emake failed" 
 * 
 * If you need support, post the output of 'emerge --info =app-misc/realpath-1.15', 
 * the complete build log and the output of 'emerge -pqv =app-misc/realpath-1.15'. 
 * The complete build log is located at '/var/tmp/portage/app-misc/realpath-1.15/temp/build.log'. 
 * The ebuild environment file is located at '/var/tmp/portage/app-misc/realpath-1.15/temp/environment'. 
 * S: '/var/tmp/portage/app-misc/realpath-1.15/work/realpath-1.15' 

>>> Failed to emerge app-misc/realpath-1.15, Log file: 

>>>  '/var/tmp/portage/app-misc/realpath-1.15/temp/build.log' 

 * Messages for package app-misc/realpath-1.15: 

 * ERROR: app-misc/realpath-1.15 failed: 
 *   emake failed 
 * 
 * Call stack: 
 *     ebuild.sh, line  54:  Called src_compile 
 *   environment, line 2248:  Called die 
 * The specific snippet of code: 
 *       emake VERSION="${PV}" SUBDIRS="src man $(use nls && echo po)" || die "emake failed" 
 * 
 * If you need support, post the output of 'emerge --info =app-misc/realpath-1.15', 
 * the complete build log and the output of 'emerge -pqv =app-misc/realpath-1.15'. 
 * The complete build log is located at '/var/tmp/portage/app-misc/realpath-1.15/temp/build.log'. 
 * The ebuild environment file is located at '/var/tmp/portage/app-misc/realpath-1.15/temp/environment'. 
 * S: '/var/tmp/portage/app-misc/realpath-1.15/work/realpath-1.15'

(źródło: http://forums.gentoo.org/viewtopic-t-831668.html)

Nie dość, że napisane jest ERROR to jeszcze portage wyświetla to na czerwono.

Ważne by zapamiętać, że to NIE JEST dobry raport błędu. Możemy to nazwać backtrace z portage, które mówi w którym miejscu przetwarzania ebuilda pojawił się błąd. W powyższym przykładzie jest to fragment

Code: Select all

 * The specific snippet of code: 
 *       emake VERSION="${PV}" SUBDIRS="src man $(use nls && echo po)" || die "emake failed" 

Można stwierdzić, że błąd był podczas wywołania polecenia (wewnętrznego portage) emake, które w rezultacie wywołuje systemowe polecenie make. Czyli jest to miejsce gdzie powstaje 99% błędów, zatem jest to informacja w tym przypadku bezużyteczna. Nie zawiera ona w sobie praktycznie żadnych informacji o istocie (przyczynie) błędu. Taki raport z góry skazany jest na pożarcie przez forumowych szyderców (ja się też niestety łapię do nich). Co zatem zrobić? Pomyśleć najpierw. Podam kilka przykładów błędów i jak je rozwiązać samodzielnie - kilka wskazówek wyjadacza. Ja co prawda korzystam z paludisa ale te same metody postępowania tyczą się również portage/emerge. Zatem do dzieła.

Błędy kompilacji
Są to najczęstsze błędy i tutaj niestety przyczyn może być wiele, i nie każdy, szczególnie osoby nie mające doświadczenia w programowaniu, poradzą sobie z tym. Przykład z mojego podwórka - dzisiaj aktualizowałem k3b do wersji 9999. Oto poprawny raport błędu:

Code: Select all

[ 56%] Building CXX object src/CMakeFiles/k3b_bin.dir/projects/k3baudioviewimpl.cpp.o
/var/tmp/paludis/app-cdr-k3b-9999/work/k3b-9999/src/projects/k3baudioviewimpl.cpp:126:2: warning: #warning enable player once ported to Phonon                                                                   
/var/tmp/paludis/app-cdr-k3b-9999/work/k3b-9999/src/projects/k3baudioviewimpl.cpp:499:2: warning: #warning Do not select hidden sources once the hiding of sources works again
/var/tmp/paludis/app-cdr-k3b-9999/work/k3b-9999/src/projects/k3baudioviewimpl.cpp: In constructor 'K3b::AudioViewImpl::AudioViewImpl(K3b::View*, K3b::AudioDoc*, KActionCollection*)':
/var/tmp/paludis/app-cdr-k3b-9999/work/k3b-9999/src/projects/k3baudioviewimpl.cpp:121: error: 'm_actionMusicBrainz' was not declared in this scope
make[2]: *** [src/CMakeFiles/k3b_bin.dir/projects/k3baudioviewimpl.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/k3b_bin.dir/all] Error 2
make: *** [all] Error 2
/usr/libexec/paludis/utils/emake: emake returned error 2

!!! ERROR in app-cdr/k3b-9999::kde:
!!! In cmake-utils_src_make at line 1478
!!! Make failed!

!!! Call stack:
!!!    * cmake-utils_src_make (/var/tmp/paludis/app-cdr-k3b-9999/temp/loadsaveenv:1478)
!!!    * enable_cmake-utils_src_compile (/var/tmp/paludis/app-cdr-k3b-9999/temp/loadsaveenv:2654)
!!!    * _execute_optionaly (/var/tmp/paludis/app-cdr-k3b-9999/temp/loadsaveenv:768)
!!!    * cmake-utils_src_compile (/var/tmp/paludis/app-cdr-k3b-9999/temp/loadsaveenv:1459)
!!!    * kde4-base_src_compile (/var/tmp/paludis/app-cdr-k3b-9999/temp/loadsaveenv:4233)
!!!    * src_compile (/var/tmp/paludis/app-cdr-k3b-9999/temp/loadsaveenv:5336)
!!!    * ebuild_f_compile (/usr/libexec/paludis/2/src_compile.bash:56)
!!!    * ebuild_main (/usr/libexec/paludis/ebuild.bash:647)
!!!    * main (/usr/libexec/paludis/ebuild.bash:675)

diefunc: making ebuild PID 9445 exit with error
die trap: exiting with error.

Install error:
  * In program paludis world -i --continue-on-failure if-satisfied:
  * When performing install action from command line:
  * When executing install task:
  * When installing 'app-cdr/k3b-9999:4::kde' replacing { 'app-cdr/k3b-9999-r1:4::installed' }:
  * When running an ebuild command on 'app-cdr/k3b-9999:4::kde':
  * Install failed for 'app-cdr/k3b-9999:4::kde'

Co tam mamy. Przede wszystkim znajdujemy słynne "!!! ERROR in .....". Ale to co istotne jest wyżej, czyli ten fragment:

Code: Select all

/var/tmp/paludis/app-cdr-k3b-9999/work/k3b-9999/src/projects/k3baudioviewimpl.cpp:121: error: 'm_actionMusicBrainz' was not declared in this scope
make[2]: *** [src/CMakeFiles/k3b_bin.dir/projects/k3baudioviewimpl.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/k3b_bin.dir/all] Error 2
make: *** [all] Error 2

Teraz warto sobie zapamiętać, że nasz problem jest najczęściej podany POWYŻEJ, a nie poniżej wspomnianego już fragmentu "!!! ERROR in .....". Zatem nie musimy nawet tego co niżej cytować, ważne jest to co powyżej, wraz z informacją o pakiecie który instalujemy. Teraz wiedząc gdzie jest błąd możemy go zgłosić lub spróbować samemu naprawić.

Spróbujmy naprawić. Raport mówi nam, że zmienna lub funkcja m_actionMusicBrainz nie jest zadeklarowana. Patrzymy zatem do pliku k3baudioviewimpl.cpp, linijka 121 a tam mamy (linijki 120-123):

Code: Select all

#ifndef ENABLE_MUSICBRAINZ
    m_actionMusicBrainz->setEnabled( false );
    m_actionMusicBrainz->setVisible( false );
#endif

Już nam powinna się nasunąć prawdopodobna bezsensowność tego zapisu - nie mamy zdefiniowanej ENABLE_MUSICBRAINZ a wywołajmy jakiś obiekt związany z tym. Zatem szybkie potwierdzenie naszych podejrzeń:

Code: Select all

# grep actionMusicBrainz -r /var/tmp/paludis/app-cdr-k3b-9999/work/k3b-9999 -n
/var/tmp/paludis/app-cdr-k3b-9999/work/k3b-9999/src/projects/k3baudioviewimpl.cpp:121:    m_actionMusicBrainz->setEnabled( false );
/var/tmp/paludis/app-cdr-k3b-9999/work/k3b-9999/src/projects/k3baudioviewimpl.cpp:122:    m_actionMusicBrainz->setVisible( false );
#

Jak widać, nie mamy nigdzie deklaracji obiektu m_actionMusicBrainz oprócz wcześniej już znalezionych. Podejrzewamy zatem, że może to zależeć od zewnętrznych bibliotek/programów - sprawdźmy to:

Code: Select all

# emerge k3b -pv

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] app-cdr/k3b-9999  USE="dvd wav (-aqua) -debug -emovix -encode -ffmpeg -flac (-kdeenablefinal) -lame -mad -musepack -musicbrainz -sndfile -sox -taglib -vcd -vorbis" 0 kB [?=>1]

Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/layman/kde-testing
 [?] indicates that the source repository could not be determined

# eix MusicBrainz
* dev-python/python-musicbrainz
     Available versions:  (~)0.7.0 {doc examples}
     Homepage:            http://musicbrainz.org
     Description:         Python Bindings for the MusicBrainz XML Web Service

* media-libs/musicbrainz
     Available versions:  
        (1)     2.1.5
        (3)     3.0.2
        {test}
     Homepage:            http://musicbrainz.org/
     Description:         Client library to access metadata of mp3/vorbis/CD media

Found 2 matches.

No tak, nie dość, że flaga USE musicbrainz nie jest ustawiona, to do tego nie mamy zainstalowane w systemie nic związane z tym. Aby się upewnić możemy sami poszukać.

Code: Select all

# grep actionMusicBrainz -r /usr/include/ -n
#

Żadnych znalezisk. Możemy zatem podejrzewać literówkę w kodzie programu, którą możemy sami naprawić. Edytujemy plik k3baudioviewimpl.cpp i zmieniamy wpis #ifndef na #ifdef otrzymując

Code: Select all

#ifdef ENABLE_MUSICBRAINZ
    m_actionMusicBrainz->setEnabled( false );
    m_actionMusicBrainz->setVisible( false );
#endif

Teraz kończymy kompilację programu, w paludisie zrobimy to tak

Code: Select all

# paludis k3b -i1 --skip-until-phase compile

w portage wyglądać to będzie tak (musicie wiedzieć, gdzie jest wasz ebuild - główne drzewo a może overlay, u mnie akurat overlay):

Code: Select all

ebuild /usr/local/portage/layman/kde-testing/app-cdr/k3b-9999.ebuild compile install qmerge clean

Po tych zabiegach wszystko ładnie się kompiluje i instaluje a my możemy pójść spać spokojnie.

Oczywiście jest to tylko jeden z milionów przykład co może pójść źle, ale wiedząc jaka jest metodyka rozwiązywania takich błędów, nawet jeśli sobie z nimi nie poradzimy sami, wiemy gdzie ich szukać, co sprawdzić w systemie, jak samemu pozyskać informacje i spróbować znaleźć problem.

Brak miejsca na dysku
Jest to błąd tak oczywisty, że zastanawiałem się, czy w ogóle pisać o niem, by czytelnik nie poczuł się urażony. Ale skoro wytykamy (sobie) błędy to nie pominiemy też tego. Również przykład z mojego podwórka, kobyła do kompilacji - openoffice:

Code: Select all

... installing module gid_Module_Root_Files_5 ...
DestDir: /var/tmp/paludis/app-office-openoffice-3.2.1/image/ 
Rootpath: /usr/lib64/openoffice 
Can't copy file: /var/tmp/paludis/app-office-openoffice-3.2.1/work/ooo/build/OOO320_m19/solver/320/unxlngx6.pro/bin/libxmlsecurity.so -> /var/tmp/paludis/app-office-openoffice-3.2.1/image//usr/lib64/openoffice/basis3.2/program/libxmlsecurity.so No space left on device at /var/tmp/paludis/app-office-openoffice-3.2.1/work/ooo/build/OOO320_m19/solenv/bin/modules/installer/worker.pm line 813.
Failed to install:  at ./ooinstall line 154.
make: *** [install] Error 1

!!! ERROR in app-office/openoffice-3.2.1::gentoo:
!!! In src_install at line 9479
!!! Installation failed!

!!! Call stack:
!!!    * src_install (/var/tmp/paludis/app-office-openoffice-3.2.1/temp/loadsaveenv:9479)
!!!    * ebuild_f_install (/usr/libexec/paludis/0/src_install.bash:48)
!!!    * ebuild_main (/usr/libexec/paludis/ebuild.bash:647)
!!!    * main (/usr/libexec/paludis/ebuild.bash:675)

diefunc: making ebuild PID 1463 exit with error
die trap: exiting with error.

Install error:
  * In program paludis --log-level qa --preserve-world --install --serialised

Jak widać, ładnie jesteśmy poinformowani o tym, że skończyło nam się miejsce na dysku. Co zrobić? Usunąć stare pliki z /usr/portage/distfiles, /usr/portage/packages, z /tmp, z /var/tmp lub jakiegokolwiek innego miejsca na dysku gdzie mogą znajdować się niepotrzebne już pliki. Potem można powrócić do kompilacji programu (tak jak w przykładzie powyżej) lub zacząć kompilację od nowa. Powiem tylko, że przerwanie kompilacji np gcc a potem jej wznowienie ale nie od początku tylko od samej kompilacji może powodować nowe błędy - więc nie należy czasem być zdziwionym tylko uruchomić kompilacje od początku.

Inne błędy
Oczywiście błędów jest masa, ale niestety nie do wszystkich posiadam świeże (jeszcze ciepłe) logi z emerge/paludisa. Jeśli będą takie oczekiwania z waszej strony, to w przypadku napotkania jakiegoś ciekawszego błędu mogę umieszczać jego analizę wraz z rozwiązaniem w tym wątku. Tak dla dobra chcących się uczyć.

No nie poradziłem sobie sam, lecę z problemem na forum
Wstrzymaj konie synu. A sprawdziłeś wcześniej forumową szukajkę? A sprawdziłeś bugzillę? Jak szukać błędów na bugzilli? Wyszukiwarka? Najprościej to wpisać w tamtejszą wyszukiwarkę nazwę naszego ebuilda, np: foo/bar. Wyświetli się nam lista wszystkich błędów związanych z tym ebuildem, patrzymy wtedy za numerkiem odpowiadającym naszej wersji i/lub opisem błędu. Jeśli znajdziemy coś podejrzanego, czytamy wątek, patrzymy na proponowane rozwiązania, patche, itp. Jeśli to nie przyniesie rezultatu, szukamy dalej, np na wyszukiwarce internetowej. Może ktoś na innej dystrybucji Linuksa spotkał się z tym i rozwiązał już? Możemy wpisać nazwę programu, dobrym pomysłem jest wpisanie też całej linijki z informacją o błędzie. Innie też je wklejają więc łatwo znaleźć pasujące wzorce.

Słowo końcowe
Mam nadzieję, że ten tekst, sprawi, że na forum przestaną pojawiać się bezsensowne raporty błędów, że forumowicze (ilu tu takich jest, co właśnie swój pierwszy post na forum zaczynają od takiego raportu) przyłożą się samodzielnie do próby znalezienia rozwiązania problemów, a kiedy ich własne siły nie wystarcza na to to wtedy dopiero zaangażują społeczność forumową w swoje problemy. A kiedy już to zrobią, to ich posty będą przedstawiały sobą konkretną wartość.

Chętnie służę swoją wiedzą, jeśli chcecie by ten watek był rozwijany to dajcie znać. Będę wtedy umieszczał kolejne przykłady (wraz z tym jak zaczną napływać). Jeśli moderatorzy uznają wątek za wartościowy, mogą go podpiąć.

[mbar]

Brawo. Dopisałbym jeszcze obowiązek podawania "emerge --info", jeśli zadajemy pytanie na forum.

[canis_lupus]

Brawo. Dopisałbym jeszcze obowiązek podawania "emerge --info", jeśli zadajemy pytanie na forum.

To akurat niekoniecznie. często jest to zupełnie zbędne.

[SlashBeast]

Przekleic ku chwale ojczyzny i wywalac wszystkie nie zgodne tematy to moze sie wkoncu naucza.

[dylon]

Niesmialo sie wtrace

O ile czesc z pokazaniem co jest wazne w komunikacie bledu jest jak najbardziej dobrya strona, to juz sugerowanie kazdemu kombinowanie z kodem zrodlowym jest w najlepszym przypadku odstraszaniem.

Nie kazdy jest deweloperem Gentoo, nie kazdy chce nim byc, nie kazdy zna sie na c lub/i c++ lub/i innych jezykach, nie kazdy wogole ma jakiekolwiek pojecie o programowaniu.

Wiec stosujac sie w 100% do "Przekleic ku chwale ojczyzny i wywalac wszystkie nie zgodne tematy to moze sie wkoncu naucza." bedzie skutkowalo odejsciem uzytkownikow od Gentoo i zostanie Was mala garstka i skonczycie jak PLD

[dziadu]

Ale ja też nie każe każdemu w kodzie grzebać. Ja sam nie jestem żadnym deweloperem, ani Gentoo ani żadnego innego projektu. Po prostu chciałem pokazać pewną metodologię rozwiązywania problemów: przeczytaj błąd, zrozum go, poszukaj przyczyn - zależności, problemów z bibliotekami. Być może przykład który pokazałem skłoni osoby, które mają jakieś pojęcie o programowaniu a boją się sami w systemie grzebać, że jednak można spróbować i naprawić. Ja też zaczynałem jako żółtodziób i musiałem się tego nauczyć - grzebałem w błędach, naprawiałem, wysyłałem patche na ebuildy i na źródła programów.

Dla przeciętnego użytkownika wystarczy, by umiał poprawnie wkleić raport błędu i go zinterpetować - w rozwiązaniu problemu pomoże wtedy społeczność. A kto chce się uczyć korzystając z mojej wiedzy temu służę w tym wątku właśnie. Kolejne realne przykłady pojawią się, kiedy jakiś problem napotkam i go rozwiążę.

[Poe]

ładnie zebrane. przykleiłem, choć znając już specyfikę tego forum, mało to da, no ale lepiej, jak pomoże to 3 na 100 odwiedzającym niż jakby nikomu miało nie pomagać

chyba czas na forumową emeryturę..