Odpowiedź forum utworzona
- Wpisy
konfliktują gcc i gcc-multilib zapytanie czy usunąć wiec daję „nie” i instalacja jest przerywana
Daj „Tak”. Obie paczki w istocie ze sobą są w konflikcie i to prawidłowe. Różnica między nimi jest wyłącznie taka, że gcc-multilib umożliwia w sytemie 64 bitowym budowę również paczek 32bitowych, zachowując całą funkcjonalność gcc. Jeśli zatem budujesz takie paczki nie masz innej możliwości.
Przy okazji – pacman nie wspiera instalacji pojedynczych paczek. Instalując cokolwiek w systemie powinieneś wpierw dokonać jego aktualizacji.Jak uruchomić Manjaro, gdy to się nie uruchamia (np. po aktualizacji).
Oczywiście w ten sposób uruchomimy wyłącznie sesję konsolową.
Porada jest właściwa dla wszystkich systemów korzystających z systemd.@Robert75: Zobacz pierwszy build – ten pakiet – sam w sobie – nie ma żadnych zależności od gstreamer0.10. Od początku. Może coś innego je ciągnęło. W Archu gstreamer0.10 został porzucony (przeszedł do AUR) z końcem lutego 2017.
Bo clipgrab-qt5 nie ma niczego wspólnego z gstreamer – jest oparty na ffmpeg – zob.: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=clipgrab-qt5
Przynajmniej obecnie.@diatryba Nie ma co się sugerować podanym przez Ciebie wątkiem, ponieważ tam chodziło o Antergos-a, a nie o Manjaro.
Jakby nie patrzeć – jest. Oprócz tego, że Manjaro ma w swoich repozytoriach całkiem pokaźną grupkę paczek, które nie są dostępne w repozytorium Archa, to:
1. Antergos jest w zasadzie Archem. Jego repozytorium zawiera minimalną ilość paczek, które nie są paczkami „systemowymi”. Aktualizacja repozytoriów w Archu to aktualizacja w Antergosie (bo korzysta z tych samych repozytoriów),
2. Manjaro dużą część paczek „dziedziczy” po Archu (po prostu przenosi je z repozytorium Archa do swojego). Z większością nic nie robi (nie wnosi żadnych zmian). W efekcie jeśli jakaś paczka wypadnie z repozytorium Archa, to już się nie pojawi w Manjaro (chyba, że ją utrzymają).
Stąd też w takich przypadkach rozwiązania dla wszystkich dystrybucji, które korzystają (nawet pośrednio, jak Manjaro) z repozytoriów Archa są prawidłowe jeśli istnieje takie rozwiązanie w Archu.Teraz powinno być tłustym drukiem, bo zdaje się, że ten temat będzie się pojawiał często w najbliższym czasie:
Jakiś czas temu z Archa wyleciały wszystkie paczki gstreamer0.10. Te paczki – m.in. z powodu ich porzucenia przez twórców jakieś 5 lat temu oraz znacznej ilości błędów (o ile wiem także związanych z bezpieczeństwem) nie są już wspierane w żaden sposób przez deweloperów Archa. Niestety – ze względu na to, że są one wymagane przez m.in. XFCE4 trafiły do AUR. Jednocześnie z Archa wypadła paczka xfce4-mixer. Nie jest już wspierana, ale też nie została przeniesiona do AUR.
Przez jakiś czas problem w Archu nie występował, albowiem wprowadzona paczka xfce4-pulseaudio-plugin zawierała informację, że zastępuje ona xfce4-mixer. Skutkiem zgłoszenia „błędu” informacja ta została usunięta. Taki też (czyli bez replace) PKGBUILD jest w Manjaro.
Obecna zatem sytuacja jest taka, że:
1. Instalacja Manjaro XFCE (bądź po prostu tego środowiska) przed porzuceniem xfce4-mixer, domyślnie wgrywała tę aplikację wraz z zależnościami czyli pluginami gstreamer0.10.
2. Obecnie z Manjaro wypadły paczki xfce4-mixer, gstreamer i libsoup-gnome.
2. Aktualizacja takiej XFCE powoduje nierozwiązywalny błąd, albowiem w miejsce libsoup-gnome wchodzi libsoup, które wyklucza się z gstreamer0.10, ale te z kolei są wymagane przez xfce4-mixer, który nie otrzymuje od systemu żadnej informacji, by miał zostać usunięty (jest coś, co go zastępuje).
Cóż – w istocie okazuje się, że rozwiązanie (choć nie jest doskonałe, ale tu już wina twórców XFCE4, że wciąż korzystają z zależności, które są dawno porzucone), jakie było pierwotnie zaproponowane w Archu było jedynym, które powoduje bezkolizyjną aktualizację. Niestety opiekun okazał się być zbyt mało asertywny i zdecydował się na usunięcie informacji w polu replace i mamy sytuację, jaką mamy.
Rozwiązania są proste i znane już na tym forum, ale podsumuję:
– odinstalować wszystkie porzucone paczki,
– dokonać aktualizacji systemu,
– ewentualnie doinstalować xfce4-pulseaudio-plugin.Odinstalowałem ten pakiet ( w ostrzeżeniu wyskoczyło, ze jest potrzebny do mixera XFCE,ale sprawdziłem działa bez tego)
Nie wiem, który z 2 pakietów odinstalowałeś (piszesz o jednym), ale jeśli to libsoup-gnome-git, to powinien Ci się (jako zależność) zainstalować libsoup – sprawdź czy masz, jeśli nie – doinstaluj.
Paczki wykorzystujące gstreamer0.10-* powinny już zostać przebudowane do używania gst-* (te pierwsze z repozytorium Archa zostały przesunięte do AUR – jeśli ktoś instalował je zanim „spadły” do AUR, to będzie miał taką paczkę w systemie, albowiem gst-* nie zastępuje gstreamer0.10-*) – znów powiem: sprawdź sobie po co masz tę paczkę (najprościej próbując ją odinstalować „na próbę”, czyli nie potwierdzając czynności).PS: To jest zupełnie inna sytuacja od tej, o której pisał rozpoczynający wątek. Po to na forach są różne wątki dotyczące różnych sytuacji, które są wyodrębnione by ktoś łatwo mógł znaleźć w nich czy coś jego nie dotyczy. Inna sprawa, że tytuł tego wątku po prostu absolutnie nic nie mówi i jego założyciel powinien zostać lekko „zmuszony” do zmiany – to jednak nie moje forum :).
@wiini – Nie, to nie jest ta sama sytuacja. Masz paczki z AUR: gstreamer0.10-good-plugins i libsoup-gnome-git. Pierwsza „chce” libsoup, druga niby ją dostarcza, ale widać obie paczki jakoś ze sobą kolidują. Po co w ogóle instalowałeś libsoup-gnome-git? To samo zawiera libsoup. Również gstreamer0.10-* jest obecnie zastąpiony przez gst-*.
Innymi słowy – zrób sobie porządek z paczkami z AUR.Prościej się nie da. Grupa pakietów składająca się na base-devel to podstawowe programy służące do kompilacji. W Archu (AUR to coś co należy do Archa) każdy PKGBUILD („instrukcja” dla kompilatora) zakłada, że cała ta grupa jest zainstalowana w systemie, stąd też w polu makedepends nie masz wymienionego żadnego kompilatora z tej grupy – dopiero, gdy jakiś kompilator do niej nie należy, a jest wymagany do skompilowania paczki, to wówczas należy go tam wymienić (np. każdy program KDE ma extra-cmake-modules).
Niemniej jednak – u Ciebie prawdopodobnie cała ta grupa jest już zainstalowana. Jeśli jednak występują jakieś błędy przy jej instalacji (jedyne co powinien system zgłaszać, to, że jest ona już zainstalowana i spytać, czy chcesz powtórnej instalacji) – załóż wątek, albowiem błędy w base-devel mogą prowadzić do wadliwej budowy paczek lub budowy wadliwych paczek.Po pierwsze, będziesz się musiał zastosować do tego poradnika.
Po drugie, albo sam coś zrobisz i się nauczysz jak postępować w takich sytuacjach, albo wykorzystasz ten PKGBUILD.
Nie budowałem, bo mi się nie chce dociągać zależności – liczę, że w pozostałym zakresie PKGBUILD jest prawidłowy. Uwaga zależności są również z AUR, zatem musisz je wcześniej zbudować; sprawdź wersje bo coś również może nie być aktualne.
Co należało zmienić? W tym PKGBUILDzie wyłącznie zmienić pole pkgver z 4.0.3 (stara wersja) na 4.0.4 (bieżąca). Następnie wpisać w konsoli, w katalogu z PKGBUILD (i źródłami) updpkgsums. Reszta w poradniku. Generalnie – jeśli tego typu błąd występuje po prostu zaglądasz w źródła, czy nie ma nowszej wersji.
Alternatywą jest zbudowanie fldigi-git, albowiem to zawsze będzie aktualne (co jakiś czas trzeba zrobić przebudowanie, bo tu nikt Ci nie podpowie, że jest „nowsza” wersja).
PS: Zawsze w takich przypadkach zgłaszasz błąd w AUR lub oflagowujesz jako nieaktualny pakiet (ten jest nieaktualny i został przeze mnie oflagowany).W wolnej chwili (a to chyba poniedziałek) postaram się zająć. Poszukaj o PRIME z Thames. To o czym pisałem o Dellu dotyczyło modelu z hybrydową.
IMO – w obecnej chwili u Ciebie, największym problemem jest dotarcie do „czystej” instalacji obu sterowników, czyli Intel (cholera, tych sterowników nawet Debian już nie używa) oraz ATI, bez „narzutów” od Manjaro.Problem nie leży w sterownikach otwartych do ATI, a w wadliwym mhwd (i jego konsekwencjach). Mam prawdopodobnie zbliżoną do Ciebie kartę (HD 7500G) i ona działa od lat na otwartych bez problemu. Zresztą wszystkie karty AMD od chwili porzucenia przez tę firmę Catalyst/Crimson działają na otwartych, włącznie z tymi, które nie obejmowało wsparcie Catalyst.
Podaj mi proszę jeszcze wynik np.
inxi -Gxx
To, że działało Ci na Catalyst, a obecnie nie działa, to tylko i wyłącznie wina skopania mhwd, który w przypadku Radeonów i wydania Manjaro 17 został po prostu spierniczony (np. proponowane sterowniki własnościowe Catalyst, dla kart, dla których winien być AMDGPU PRO).
I jeszcze jedno pytanie – „wiki Archa nic nie wprowadza”… coś bliżej?PS: Sprawdzałem – Twój Dell w zasadzie bez problemu i w całości obsługiwany jest przez Archa (a zatem na otwartych sterownikach i PRIME). Problem zatem nie leży ani w sterownikach Intela, ani w sterownikach otwartych AMD, ani w samym PRIME, a tylko i wyłącznie musi leżeć w wadliwym mhwd (i wszystkim, co z nim związanym, niewykluczając owego dziwacznego bumblebee dla tego układu).
Jak już kiedyś powiedziałem – nie będę doradzał, bo więcej zaszkodzę, ale kilka rzeczy jest zastanawiających.
Przede wszystkim powinieneś mieć zainstalowany sterownik video-hybrid-intel-ati-bumblebee. Tak twierdzi mhwd. Niemniej jednak lokalne przeszukanie pakietów pacmanem za wszystkimi paczkami zawierającymi w nazwie słowo bumblebee paczki tej nie wykazuje.
Można pokusić się o instalację tego sterownika (mimo wszystko chyba bez „-f”, przynajmniej na początek). Inna sprawa, że jakieś sterowniki dostarczyły Ci moduły tak dla Intela, jak i dla AMD. Znów możesz odpytać system o paczki zawierające intel oraz ati (tu bym spytał też o amd i radeon).
Drugie – wg wszelkich danych masz układ Intel/AMD, który obsługuje PRIME, a nie bumblebee, które jest dla Intel/NVidia (tak wiem, nazwa paczki nic nie mówi – można sobie ją nadać dowolną, a powyższa pochodzi od Manjaro, a nie jest jakąś „ogólną” – to zresztą pewien rodzaj skryptu, czy ustawień). Nieistotne. O wiele istotniejsze, że plik bumblebee.conf zawiera wyłącznie specyficzne ustawienia dla obu sterowników NVidii, dla AMD – nie (i słusznie, bo on jej po prostu „oryginalnie” nie wspiera AMD; zresztą analiza PKGBUILDu wskazuje, że on nic wspólnego z AMD raczej nie ma).
Sprawdziłbym zawartość katalogu /etc/bumblebee – może tam są jakieś (może w jakimś podkatalogu) ustawienia.
Trzecie – wg mnie to jakiś błąd mhwd (nie jeden zresztą) i pewnie należałoby go zgłosić na bugzilli Manjaro. Znów powiem – nie traktuj to jako porady, bo mnie zaraz ktoś zjedzie, że „Manjaro ma swoje ustawienia i specyficzne narzędzia” (no fakt – ma; problem, że nie działają 100/100 co jest zresztą normalne i nie dotyczy tylko narzędzi Manjaro broń boże) – ale skoro owe „specyficzne narzędzia” Manjaro nie działają w Twoim przypadku, to być może sięgnąć po rozwiązania dostępne w każdej innej dystrybucji, a nie zdawać się na automatyzm? Link do wiki PRIME w Archu podał Ci @aquila. Nie namawiam – rozważ.Jeszcze zanim ta reinstalka. Masz możliwość wejścia do GRUBa. Odnajdź tam linijkę, w której będzie słowo „quiet” i je wykasuj, a następnie uruchom dalsze bootowanie systemu. Powinny się pojawiać jakieś informacje widoczne na ekranie, aż dojdzie do momentu, w którym system „stanie”. Wówczas:
– spróbuj tego co pisze Michał (alt+ctrl+fx lub alt+fx) – jedno z nich winno zadziałać (x to oczywiście numer klawisza funkcyjnego); jeśli się uda to już wiele razy napisali Ci aquila i michaldybczak co masz dalej robić,
– pokaż nam (tylko nie zdjęciem, które jest kompletnie nieczytelne) na czym stanął system,
– oprócz domyślnego obrazu kernela powinieneś mieć jeszcze jeden – fallback – spróbuj uruchomić też na nim – może się podniesie (niestety nikt nie wie co zrobiłeś, że popsułeś system (obawiam się, że nie masz jeszcze jednego obrazu o nazwie „tryb ratunkowy” lub „recovery”, gdybyś miał, to jest on najsensowniejszy, bowiem zawsze wówczas system się uruchomi, trzeba jednak wówczas uważać, bo jesteś na uprawnieniach roota, a linuksowej wiedzy raczej niewiele masz).
