Ik moet dus naar 42.2 als ik nog updates wil krijgen.
Nu heb ik echter net een programma zelf gecompileerd, LMMS rc 1.2 en dat is elke keer vooral lastig, omdat je alle afhankelijkheden moet zoeken.
Er is wel een lijst van de afhankelijkheden ( dependecies), maar daar ontbreken dingen aan.
Ik ben al dagen aan het zoeken geweest, maar vind geen duidelijk antwoord waar ik wat aan heb.
Vraag1
Begrijp ik het nou goed, dat als ik een update uitvoer, en ik mazzel heb, ik LMMS niet opnieuw hoef te compilen ? ( ik weet even niet wat compilen in het nederlands is )
Vraag 2
Kan ik een lijst maken van de afhankelijkheden, van de LMMS versie die ik zelf gecompileerd heb? Via de opdracht prompt ?
Op mijn computer staat nu ook een andere versie van lmms, van packman, die is op de normale manier via yast geïnstalleerd is.
Vraag 3
Is een update uitvoeren (42.1 -> 42.2) ipv een gewone installatie, vragen om problemen, als je de nvidia drivers gebruikt ?
Beetje off topic, ik heb de 42.2 iso natuurlijk al met bittorrent binnen gehaald, helaas ging het branden van de dvd mis, en dat was waarschijnlijk het einde van mijn huidige brander.
Ik heb inmiddels een nieuwe dvd brander binnen. Je blijft lachen met die computers. :sarcastic:
Ik haal altijd mijn openSUSE iso’s altijd binnen met Bit torrent, stukje traditie inmiddels. Gebruik ik bit torrent tenminste af en toe ook waar het voor gemaakt is.
Je kunt de 42.1 in je repos vervangen door 42.2 en dan
zypper dup
draaien. Is nooit meteen definitief, dwz je moet ja/nee kiezen, maar wordt openQA getest en zou gewoon moeten werken.
Overigens is zelf compileren op deze manier niet de ‘way to go’. Dan loop je altijd, per definitie, tegen dit soort dingen aan.
Waarom trouwens nog branden op DVD? Imagewriter of dd gebruiken en je zet 't op USB-stick, en die 8GB dingen kosten geen drol meer.
Bedankt.
Tja waarom nog dvd, is denk ik vooral gewoonte, maar met de prijzen van usb sticks is dat eigenlijk wel achterhaalt.
Dat zelf compilen, heeft er mee te maken, dat er problemen zijn met opensuse leap 42.2 (en andere distro’s) met LMMS.
Met leap 42.1 geen probleem met LMMS.
Om misverstanden te voorkomen, het probleem in deze is LMMS, niet ons favoriete besturingssysteem.
De versie die we van Packman krijgen werkt op 42.1 wel goed, maar op 42.2 mist er iets. ( dat is ook waarom ik geen haast had om te updaten, want ik weet al, dat als ik update naar 42.2, ik een probleem heb met lmms van packman )
LMMS is gratis en heeft hulp nodig ook van mensen als mij. Ik had dus een poging gedaan om te kijken of de nieuwste release kandidaat goed wilde compilen op 42.1.
Het goede nieuws in deze is, dat ook op 42.2 al een opensuse gebruiker succes vol was met het compilen van de release kandidaat.
Het is wel cynisch dat een programma dat eigenlijk Linux Multi Media Studio heet, tegenwoordig zoveel problemen heeft op Linux.
Voorlopig is voor mij en vele andere helaas de enige optie compileer LMMS zelf, want packman gaat voor ons geen beta versies en release kandidaten compileren.
( Daar hebben ze wat mij betreft 100% gelijk in )
Of zie ik een optie over het hoofd ?
Tot slot over
zypper dub
Ik had nou juist ook op dit forum gelezen, dat het beter was om een dvd te branden of een usb stick te maken, en vanaf daar de update te doen.
Dat zou minder kans op problemen geven.
Spreek me gerust tegen als dit niet zo is.
42.1 veranderen in 42.2 ( en voor de zekerheid even de niet standaard repositories uitzetten ) is natuurlijk de makkelijkste manier om te updaten.
Over ‘zypper dup’ na verandering van de repos: deze manier is zelfs beter dan via de DVD, zeker als je de online bronnen niet inschakelt, of niet kunt inschakelen omdat je dan tegen de nare bug in de NL vertaling aanloopt. Zonder die bronnen kun je de pakketten die niet op de dvd staan, maar die je wel geïnstalleerd had, kwijt raken. Met ‘zypper dup’ heb je dat probleem niet.
Overigens worden beide methoden via openqa.opensuse.org getest. Als je op deze pagina naar beneden scrollt kun je dat ook zien. Zelfs upgrade van 13.1, 13.2 worden zo getest. Wat daar gebeurt is nadoen wat een gebruiker ook zou doen. Bijv. Loopt de installatie zoals het moet, herstart het systeem OK na installatie, start Firefox op en krijg je dan netjes de startpagina? En dus niet of de NL talige installatie goed loopt, anders zou die test mislukt zijn, er een bugreport uitrollen en het voor release gefixt zijn. Klik daar maar eens wat rond, en kijk vooral naar met lichtblauw gemerkte zaken, dat zijn lopende/komende tests, als je dat 's gezien hebt spreekt het meer.
Over LMMS en 42.2: als je LMMS vanuit een terminal opstart, zou je moeten kunnen zien wat er mist/misgaat. Met de Packman versie dan hè.
Ik ga het proberen, als het echt misgaat moet ik nog wel de leap 42.1 dvd hebben.
Het behouden van geïnstalleerde pakketten klinkt als wat ik wil.
Over LMMS, ik had het al gemeld bij packman, en hun antwoord was dat dit upstream gerepareerd moet worden.
Upstream is in dit geval LMMS.
Op detail niveau gaat het mij boven de pet, maar er is iets waardoor het compilen op bijna alle Distro’s fout gaat.
Ook met leap 42.1 is er dezelfde foutmeding bij het compileren, maar toch werkt het op 42.1 wel.
LMMS heeft zoals alle soortgelijke muziek programma’s een plugin container. Deze ontbreekt als je lmms van packman installeert op 42.2.
Ik denk niet dat het zinvol is dat ik daar verder op inga, tenzij er hier lmms gebruikers zijn met problemen.
De oplossing is voorlopig om de laatste versie van lmms zelf te compileren.
De lijst met afhankelijk heden voor ons ( leap ) moet inmiddels redelijk compleet zijn. ( lmms web pagina’s )
Een 42.2 gebruiker en ik, hebben namelijk een aanvulling gedaan.
Even terzijde: als je dichter op upstream wilt zitten, zou je ook Tumbleweed kunnen overwegen. De lmms versie van Packman start hier in ieder gevak goed. Om meer te kunnen zeggen is 't te lang geleden dat ik er mee gespeeld heb. Ik weet niet hoe je zit me de ruimte op je systeem, maar je zou zelfs 42.2 en TW allebei kunnen installeren, gebruik makend van dezelfde homedir. Heb ik op mijn laptop en dat werkt prima.
Ik gok dat je zeker Carla, maar veel belangrijker VeSTige mist in LMMS ? ( Met Vestige dat ook wine gebruikt, zijn overigens de meeste problemen )
Links onder instrument plugins.
Of misschien makkelijker ik denk dat je versie lmms 1.1.3 krijgt van packman ( op thumble weed ? )
Los van LMMS klinkt het wel interessant om ook Thumble weed te gebruiken met de zelfde home dir.
Gebruikt Thumble weed dan ook de zelfde swap ?
Harde schijf is 1 terra , daar kan wel 20 gig vanaf voor de root van thumble weed.
Gaat denk ik niets oplossen met lmms, maar is minimaal leuk omdat het kan.
Beetje veel vragen, maar op bijna alles: ja dat kan.
Wat jij compileert heeft bepaalde dingen/modules/componenten ( gaat voor zover ik weet over VST (Vestige) die niet overall vrij mogen worden verspreid ( zoals voorheen ook mp3 ) ) aan staan en bij Packman mag dat niet. Er wordt gewerkt aan andere oplossingen, zodat het codecs gedoe etc. echt opgelost worden.
Ik weet dat lmms aan een Linux installer werkt. Ik als Linux fan weet niet of ik daar echt blij mee ben.
De gebruiker in mij ziet het wel zitten. ( als het maar werkt )
Probleem voor veel gebruikers is wel, dat een muziek programma dat geen vst kan gebruiken, eigenlijk geen optie is.
Verder weet ik dat vst van Steinberg is, en daar zal wel het probleem zitten, qua licenties.
Een voorbeeld van een leuke vst, de mini moog.
Een software versie van een legendarische syntjesizer.
Gary Numan - are friend electirc ? bijvoorbeeld. ( maar de lijst is lang )
een .changes file met daarin een changelog ( in deze staat niks )
een .spec file, waarin eigenlijk staat wat je nu allemaal met de hand gedaan hebt. Van ieder pakket is ook een …src…rpm, als je die opent met Ark zie je de spec file die erbij hoort. Voor LMMS zou ik dan beginnen met die van Packman, en die aanpassen waar nodig.
De voordelen:
Bouwen voor meerdere openSUSE ( evt. andere distros ) tegelijk
Je krjigt niet al die -devel pakketten op je systeem
Je kunt het binnentrekken van nieuwere sources automatiseren, het opnieuw bouwen van de pakketten wordt dan automatisch in gang gezet.
Andere pakketten in OBS als voorbeeldmateriaal
Bij Packman gebruiken ze ook OBS, dus met hun spec file zou je al een heel eind moeten komen.
Ik zocht recentelijk een programma, en vond dit ook, maar het mp3 gedeelte werkte niet.
Tegen dit soort dingen loop ik vaak aan, met obs pakketten.
Alleen al om andere openSUSE gebruikers te helpen zou ik graag een rpm beschikbaar stellen. ( wat dan misschien ook wel voor Fedora werkt )
Er is inmiddels een lmms 1.2 rc 3
( release candidate 3 )
Ik kwam bij het compileren overigens geen gekke dingen tegen. Alle libs en dev pakketen kon ik gewoon vinden via de officiele bronnen.
Al was het soms wel even zoeken, naar welk opensuse pakket een benodigde lib leverde.
Gelukkig heeft YAST, ook de zoek term, rpm provides.
En google is in deze je vriend.
Die beperking is er, ja. Het probleem ligt 'm voornamelijk in de VS, maar qua mp3 zou je daar geen last meer van mogen hebben, omdat we als distro van FLUENDO een licentie hebben gekregen. Die zit niet in de OSS repo, omdat we vastgelegd hebben dat we de FOSS principes hanteren, maar wel in de Non-OSS repo ( FLUENDO lever alleen binaries ). Sommige pakketten zullen daar misschien nog niet op afgesteld zijn, andere zullen niet genoeg hebben aan alleen deze licentie. Om dit soort redenen zit Packman ook in Duitsland. En kunnen we in OBS, zeker in de officiële repos alleen pakketten neerzetten die “crippled” genoemd worden.
In Europa mogen we op dit gebied heel veel. Bijvoorbeeld versleutelde dvd kijken, kopiëren voor thuisgebruik, mp3 maken van eigen CD’s etc. Maar, er zijn staten waar je de technologie ( lees software ) daarvoor niet eens mag gebruiken, laat staan verspreiden, waar het hebben van mp3 bestanden waarvan je niet kunt aantonen dat je ze gekocht hebt, strafbaar is. En dan zijn er ook nog landen waar het normaal is om daar de verspreider ( lees openSUSE ) verantwoordelijk te maken ( lees te laten betalen ). We weten ook dat andere distros hun eigen manieren hebben om het hele codec ( daar draait het om ) verhaal te omzeilen. Ik kan daar op dit moment alleen over zeggen, dat daar aan gewerkt wordt. Dwz. dat je net als bij bijv. Mint alleen nog maar hoeft te zeggen “Doe me die codecs maar”.
Ik zelf heb zeer tegenstrijdige gevoelens tav die licenties.
De gebruiker in mij wil natuurlijk dat het gewoon werkt.
De Linux fan, die het voor een groot gedeelte eens is met Richard Stallman, maar zeker met het foss principe, is erg blij met openSUSE.
Zelfs toen dit problemen gaf met de steam (valve) licentie, die zoals ik hem begreep. er inderdaad op neer kwam dat bij problemen ook (open)suse aansprakelijk was.
Dit conflict tussen de Linux fan in mij, die Linux niet alleen maar draait omdat het gratis is, en de gebruiker is er wel vaker.
Zo vind ik het best jammer dat gamen met de opensourcedrivers geen aanrader is. ( alien isolation onder andere )
Toch is er wel vooruitgang, want steam doet het inmiddels ook op de opensource drivers, en ik dacht dat de spellen die valve zelf maakt, inmiddels ook werken met de opensource drivers.
Tot slot, een beetje jaloers op de mint gebruikers was ik wel. ( inderdaad alleen maar vanwege het codec verhaal )
Dat er gewerkt word aan een betere oplossing, is dus goed nieuws.
Probleem is dus wel, dat ik waarschijnlijk geen volledige versie van lmms kan (mag) compileren op de obs.
Net gelezen: patent op MP3 afspelen is verlopen, op MP3 maken verloopt eind december. En er zijn er nog een paar die dit jaar verlopen en dan dus vrijelijk verspreid kunnen worden ( daardoor kan dan bijv. ffmpeg zonder beperkingen verspreid worden, en dan heb je eigenlijk alles al ).
Als ik het goed heb begrepen zijn er als gevolg van verlopen patenten in Tumbleweed al libraries verplaatst van Packman naar OSS (dat werkt natuurlijk niet goed als je --no-allow-vendor-change gebruikt en daarom zijn er draden over).
Bij Leap gebeurt dat uiteraard pas op zijn vroegst in 42.3 (en dan gaat het vanzelf bij een correct uitgevoerde upgrade).
Ik krijg het volgende probleem voor geschotelt, en heb de update toen maar afgebroken.
File /usr/share/locale/zh_TW/LC_MESSAGES/libktorrent.mo
from install of
libktorrent6-lang-2.0.1-1.1.noarch (Main Repository (OSS))
conflicts with file from package
libktorrent5-lang-1.3.1-7.1.noarch (@System)
Ik zal dus wel te weinig repositories uitgezet hebben, maar ben het spoor nu even bijster.
Hier een print screen van yast update bronnen.
Ik heb geen idee bij welke repository noarch is hoort ?
Alleen een (fout)melding geeft ons te weinig informatie. We moeten ook weten wat je doet. Dus de kopieëerslag beginnen van en met de prompt, tot en met de volgende prompt. We zien nu ook niet wat er voor oplossingen worden geadviseerd en kunnen dus ook geen advies daarover geven.
Repo listing svp door kopie/plak van
zypper lr -d
. Dan krijgen we geen hoofdpijn van het bestuderen van priegelplaatjes.
‘noach’ betekent dat het pakket architectuur onafhankelijk is. Dus het is hetzelfde pakket voor 32-bit, 64-bit, andere dan Intel architecturen. En dat klinkt logisch, want het gaat duidelijk om een ‘lang’ pakket. Dus een pakket dat de boodschapppen in allerlei talen voor een product bevat.
Tja, dat zijn best wel wat repos. Hoe ziet je update commando eruit?
Kun je 's output laten zien van
# zypper dup --no-allow-vendor-change
? Ik ben wel benieuwd. Dit is eigenlijk hoe je TW update, maar waarom zou 't in dit geval niet werken. Pakketten zouden dan gewoon uit de 42.2 versie van dezelfde repo ( =vendor, tenminste vaak ) moeten komen.
Ik heb ik yast elke repository met 42.1 in de naam veranderd naar 42.2.
Daarna heb ik denk ik, alle extra repositories uitgezet. ( oa packman en nvidia)
Toen
sudo zypper refresh
en daarna
sudo zypper refresh
Bij de laatste kreeg ik dus de boodschap , dat hij twee keer het zelfde pakker ziet ( zoals ik het begrijp)
Als het alleen maar om een taal pakket gaat zou ik kunnen kiezen voor doorgaan ?
Ik zit nu wel te denken, vanwege de opmerking, allow no vendor change.
Ik heb nadat ik packman toevoegde op 42.1 een vendor change gedaan, maar heb packman nu uitstaan.
Waarom ik dat gedaan heb ? Ik las ergens dat je beter de extra repositories uit kon zetten, en dan na de update, deze waar aanzetten.
