PDA

View Full Version : KDE 4.10.4 rel10



pieter1602
03-Jul-2013, 04:44
Hoi Forum
Ik gebruik KDE 4.10.4 rel10 al een tijdje nu veel updates waarvan 1 confict:

#### YaST2 conflicts list - generated 2013-07-03 13:33:36 ####

kdebase4-workspace-4.10.5-2.1.x86_64 vereist kdebase4-workspace-branding = 4.10.5, Maar aan deze eis kan niet voldaan worden
niet-installeerbare aanbieders: kdebase4-workspace-branding-openSUSE-12.3-3.1.i586[openSUSE_12.3]
kdebase4-workspace-branding-upstream-4.10.5-2.1.i586[openSUSE_12.3]
kdebase4-workspace-branding-openSUSE-12.3-3.1.x86_64[openSUSE_12.3]
kdebase4-workspace-branding-upstream-4.10.5-2.1.x86_64[openSUSE_12.3]
[ ] kwin-4.10.5-2.1.x86_64 niet installeren

[ ] De volgende acties zullen uitgevoerd worden:
kdebase4-workspace-4.10.5-2.1.x86_64 niet installeren
kwin-4.10.5-2.1.x86_64 niet installeren
kdebase4-workspace-plasma-calendar-4.10.5-2.1.x86_64 niet installeren
[ ] waardeer kdebase4-workspace-branding-openSUSE-12.3-4.2.x86_64 af tot kdebase4-workspace-branding-openSUSE-12.3-3.1.x86_64

[ ] De volgende acties zullen uitgevoerd worden:
kdebase4-workspace-4.10.5-2.1.x86_64 niet installeren
kwin-4.10.5-2.1.x86_64 niet installeren
kdebase4-workspace-plasma-calendar-4.10.5-2.1.x86_64 niet installeren
[ ] breek kdebase4-workspace-4.10.5-2.1.x86_64 door enige van zijn afhankelijkheden te negeren

Bij dit soort conflicten Is er dan een soort regel die je het beste standaard kan toepassen als je niet weet welke oplossing je het best kan kiezen.:\

hcvv
03-Jul-2013, 09:45
De standaard reaktie is: Afbreken. En eerst zelf beredeneren wat er mis is en dus wat een veilige oplossing is, of eerst vragen (wat je dus nu doet, heel goed!).

Zelf denk ik aan twee mogelijkhededen:
a) je hebt een foute combinatie van repos;
b) ze hebben een fout gemaakt.

In geval a)) kun je eventueel hier

zypper lr -d
posten zodat wij mee kunnen kijken.

In geval b), even afwachten, dan wordt het waarschijnlijk in een paar dagen opgelost omdat anderen het ook hebben.

pieter1602
03-Jul-2013, 10:51
Ik was zelf al pogingen tot beredeneren aan het doen maar kwam tot de conclusie dat het een gok zou zijn dus dacht ik beter vragen.:)
En de uitkomst van :

zypper lr -d
1 | Application:Geo | Application:Geo | Nee | Nee | 99 | rpm-md | http://download.opensuse.org/repositories/Application:/Geo/openSUSE_12.3/ |
2 | KDE_Release_410_openSUSE_12.3 | KDE_Release_410_openSUSE_12.3 | Ja | Ja | 99 | rpm-md | http://download.opensuse.org/repositories/KDE:/Extra/KDE_Release_410_openSUSE_12.3/ |
3 | ftp.gwdg.de-suse | Packman Repository | Ja | Ja | 99 | rpm-md | http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_12.3/ |
4 | home:OpenFTD | home:OpenFTD | Nee | Nee | 99 | rpm-md | http://download.opensuse.org/repositories/home:/OpenFTD/openSUSE_12.3/ |
5 | libdvdcss | libdvdcss | Nee | Nee | 99 | rpm-md | http://opensuse-guide.org/repo/12.1/ |
6 | openSUSE_12.3 | openSUSE_12.3 | Ja | Ja | 99 | rpm-md | http://download.opensuse.org/repositories/KDE:/Release:/410/openSUSE_12.3/ |
7 | openSuse_12.3 | openSuse 12.3 | Ja | Nee | 99 | yast2 | iso:///?iso=opensuse123.iso&url=file:/// |
8 | repo-non-oss | openSUSE-12.3-Non-Oss | Ja | Ja | 99 | yast2 | http://download.opensuse.org/distribution/12.3/repo/non-oss/ |
9 | repo-oss | openSUSE-12.3-Oss | Ja | Ja | 99 | yast2 | http://download.opensuse.org/distribution/12.3/repo/oss/ |
10 | repo-update | openSUSE-12.3-Update | Ja | Ja | 99 | rpm-md | http://download.opensuse.org/update/12.3/ |
11 | repo-update-non-oss | openSUSE-12.3-Update-Non-Oss | Ja | Ja | 99 | rpm-md | http://download.opensuse.org/update/12.3-non-oss/


En na het instaleren van KDE 410 en van de KDE 410 extra heb ik hierop een schakel systeem paketten gedaan en ook op Packman.

hcvv
03-Jul-2013, 11:47
Als ik zypper lr -d doe, krijg ik als eerste een regel met de koppen van de kolommen. Vreemd dat jij dat niet hebt.

Ik zie eigenliijk niets verdachts. En als je deze combinatie al langer gebruikt zonder problemen, schuif ik het toch op een probleempje bij de "packager".

Je zou nog eens in YaST > Software > Softwarebeheer kunnen gaan en dan kdebase4-workspace-branding in het zoekveld zetten. Dan rechts selecteren en rechts onder de tab Versies gebruiken. Je ziet dan welke repos dat ding hebben en welke geïnstalleerd is.

pieter1602
03-Jul-2013, 13:23
Dat van die eerste regel klopte:shame:Ik ben bang dat ik dat eerste gedeelte niet mee gekopieerd had,Dus dat lag aan mij.
Heb gekeken bij versies en het enige wat ik tegen kom dat de leverancier is
obs://build.opensuse.org/KDE en dat die dus is geinstaleerd.

Knurpht
03-Jul-2013, 14:37
Het probleem is dat er met de nieuwe KDE pakketten niet ook een nieuw openSUSE-branding pakket is aangemaakt. En da's wat mij betreft nou het enige punt waarop ik 't aandurf om te zeggen dat 't probleem genegeerd kan worden: breek ......
De branding pakketten zijn ook versie afhankelijk maar veranderen eigenlijk niet. Aangezien je ook de optie hebt om het branding pakket af te waarderen (is betrekkelijk) zou ik eerst die proberen. Mocht dat alleen maar meer problemen opleveren, dan zou ik de boel afbreken, software installer opnieuw starten en kiezen om de afhankelijkheid te negeren.

hcvv
04-Jul-2013, 03:04
Dat van die eerste regel klopte:shame:Ik ben bang dat ik dat eerste gedeelte niet mee gekopieerd had,Dus dat lag aan mij.
.
Hm, maar het commando was er wel, dat heb je dus met de hand toegevoegd. Volgende keer graag copy/paste inclusief de prompt, het commando, de uitvoer en de volgende prompt. Dat maakt dat de lezers het gevoel krijgen dat dit betrouwbare, echte uitvoer is, waar niet mee is geknoeid. Denk nooit dat je wel iets weg kan laten. Tenslotte heb jij een probleem en vraag je hulp aan anderen omdat je mogelijkerwijs iets over het hoofd ziet. Als je dan iets weglaat is het logisch dat je dat weglaat wat belangrijk is. Dat is menselijk, maar fataal in de discussie met je helpers.

Ik ben het met Knurpht eens dat die branding eigenlijk niet zo belangrijk is, maar storend is zo'n fout wel.

Knurpht
04-Jul-2013, 03:23
Wat hier denk ik ook een rol zou kunnen spelen, is dat KDE ook geupdate wordt via de Update repo. Als er dan geen vendor switch is gedaan naar de KDE:Release repo krijg je ook conflicten. Maar volgens mij heeft Pieter die al lang gedaan.

hcvv
04-Jul-2013, 03:37
Wat hier denk ik ook een rol zou kunnen spelen, is dat KDE ook geupdate wordt via de Update repo. Als er dan geen vendor switch is gedaan naar de KDE:Release repo krijg je ook conflicten. Maar volgens mij heeft Pieter die al lang gedaan.
Ik wilde die Vendor switch controleren door hem naar de verschillende "leveranciers" te laten kijken. Maar dat levert dus niets op.

Knurpht
04-Jul-2013, 04:28
Even gecheckt bij een klant waar dezelfde KDE repos gebruikt worden. Men heeft daar de policy afbreken-morgen-weer-proberen, maar was gisteren op hetzelfde conflict gestuit. Er zal een branding-pakket niet gebouwd zijn, of een specfile niet aangepast. Dan is het pakket er wel, maar wordt niet als kandidaat gezien. Het laatste had ik vorige week met de kdm-branding op KDE 4.11 beta

hcvv
04-Jul-2013, 04:47
Ok, ik was al een beetje verbaasd dat er niet nog meer meldingen waren. Mij leek het niet zo uitzonderlijk wat Pieter doet.

pieter1602
04-Jul-2013, 14:26
Ik heb het branding pakket afgewaardeerd en verder de updates geinstaleerd en kwam daarna niets geks meer tegen of vreemds:\.
En ja ik had die switch gedaan op die KDE repo en die KDE/Extra repo en ook op de packman repo.En dat kopieer foutje dacht ik, ik houd het zo klein mogelijk en doe alleen dat wat nodig is anders neemt het zoveel ruimte in beslag:shame:.Zal niet weer gebeuren.

dan zou ik de boel afbreken, software installer opnieuw starten en kiezen om de afhankelijkheid te negeren.

En Knurpht deze snap ik eigenlijk niet helemaal als ik hem al heb afgewaardeerd Dan heb ik al een actie ondernomen Dan kan ik toch niet weer een keuze mogelijkheid krijgen.
:\

hcvv
05-Jul-2013, 01:05
Het slechts gedeeltelik copieëren is je al lang vergeven. In dit geval moest ik zelf een zypper lr -d maken om te zien welke ja/nee bij welke kolomkop hoort.
Sommigen denken dat wij alles uit ons hoofd weten. Dat is niet zo. We weten alleen waar we iets kunnen vinden en waar we (zoals een jonge hond, maar dan gerichter) aan moeten gaan rukken om misschien iets belangrijks boven te krijgen. Dan is het frustrerend als iemand (uit onwetendheid, maar niet de instructies volgend) denkt zelf wel uit te maken wat wel en wat niet te posten.

Aan een prompt kunnen we bijvoorbeeld zien:
. welke shell wordt gebruikt (laatst was er iemand die de C-shell gebruikte, dat niet vertelde en toen ik hem een bepaald commando vroeg uit te voeren postte hij alleen een C-shell foutmelding waar ik niets van snapte);
. wat de "working directory" is voor het commando;
. of er als root wordt gewerkt of niet.
Allemaal zaken die belangrijk kunnen zijn.

En aan het gepostte commando kunnen we natuurlijk zien wat er precies is getikt. Sommigen zeggen: "En het xyz commando geeft:", terwijl blijkt dat ze xyz -abc (met opties dus) hebben gedaan als je het echt ziet.