# 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):

```
 * 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: https://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

```
 * 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:

```
[ 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:

```
/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):

```
#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ń:

```
# 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:

```
# 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ć.

```
# 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

```
#ifdef ENABLE_MUSICBRAINZ

    m_actionMusicBrainz->setEnabled( false );

    m_actionMusicBrainz->setVisible( false );

#endif
```

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

```
# 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):

```
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:

```
... 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ąć.Last edited by dziadu on Thu Jul 29, 2010 12:43 am; edited 1 time in total

----------

## mbar

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

----------

## canis_lupus

 *mbar wrote:*   

> 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  :Razz: 

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  :Razz: 

----------

## 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ć  :Smile: 

chyba czas na forumową emeryturę..

----------

