Hallo,
ich habe gerade das siduction KDE Next Repo hinzu gefügt, und den Experimental Zweig samt der /etc/apt/preferences.d/kde-experimental entfernt, vielen Dank für Eure Arbeit.
Nun ist mir aufgefallen, dass im KDE-Next Repo das aktuelle digikam samt kipi-plugins fehlt.
Nun ist zwar zur Zeit digikam 2.6.0 beta1 in debian experimental aktuell, es ist aber ordentlich nutzbar, wie schon 2.4 und 2.5.
Wer damit gearbeitet hat, möchte nicht mehr die Version 1.9.0, die zur Zeit in unstable aktuell ist.
Ich bitte um Hinzufügen der aktuellen digikam- und kipi-Pakete in das KDE-Next Repo.
Wer es konservativer möchte, kann ja dann immer noch auf die Version 1.9.0 in unstable zurück greifen.
Viele Grüße,
Holger
+1
Hallo Alf,
ich lese gerade von Deinen Bemühungen um eine aktuelle digikam Version, vielen Dank für Deine Bemühungen.
Wenn digikam 2.6.0 Beta 1 von Experimental zu experimentell ist, was wäre dann gegen die ältere Version 2.4.0 aus Snapshot zu sagen? Gerade 2.4.0 lief bei mir und auch meinem Vater sehr gut. Bei der 2.5.0 musste man einen Kartenleser für den Fotoimport bemühen, weil der PTP-Mode ein wenig kaputt war, sonst ging die auch gut.
Und wie schon geschrieben: Wem der Kram zu heiß ist, der kann ja bei 1.9.0 aus Unstable bleiben.
Viele Grüße,
Holger
@holger und lanzi,
ich hab hin und her überlegt. Im Endeffekt hab ich mir bei devil Rat geholt ;) Ich hab wirklich ernste Probleme, digikam nach kdenext zu packen. Das gehört da einfach nicht hin, weil ich das dann jedem User aufs Auge drücke, ob er will oder nicht.
Wogegen ich aber nichts einzuwenden habe, ist ein Transfer der benötigten Pakete nach packages.siduction.org/experimental. Das Repo ist sehr überschaubar, wer es sich einbindet, weiss, worauf er sich einlässt und das nervige Pinnig gegen debian/experimental fällt einfach mal weg. Einen Rückgriff auf die snapshot-Repos halte ich für nicht unbedingt zielführend, das würde recht unwartbar sein.
Siduction-Experimental hat einen weiteren Vorteil: Durch die Struktur des Repos kann man bei Problemen debian/experimental durch eigene Fixes einfach mal komplett schmerzfrei übersteuern. (aka passt mir die debian-Variante nicht, bekommt die siduction-Variante eine ausreichend hohe Nummer). Das wird zwar mit Garantie auch nicht ohne Probleme ablaufen, das ist dann echtes bleeding edge. Das kann nicht nur beissen, das wird auf jeden Fall blutig. Da seid ihr als Benutzer dann mit in der Pflicht.
Hallo agaida. Danke Dir für Deine Mail und Deine stetige Bemühungen.
Quote
Wogegen ich aber nichts einzuwenden habe, ist ein Transfer der benötigten Pakete nach packages.siduction.org/experimental.
Klingt für mich auf jedem Fall nach einem Plan :-)
Insgesamt hat die Sache für mich eine untergeordnete Priorität, aber es wäre cool. Wenn es mit viel Aufwand verbunden ist, lass es! Man kann auch immer aus experimental installieren.
Aber wenn DU es tust, dann bitte immer mit den passenden Kipi-pluggins.
Auch Holgers Idee mit der version aus Snapshot finde ich gut.
Danke!
Die Überlegung mit dem Experimental war in so fern gut, weil das lebt. Ich tackere die entsprechenden Updates in das Zielrepo und den Rest macht ein Script. Snaps sind tot. Die darf man manuell nachhalten. Das bedeutet, bei jeder Pillepalle-Änderung neu testen. Bei jedem Mal. Fixen und Patches gen debian und/oder Upstream bringt mehr im Longrun.
Hallo Alf,
digikam samt kipi-plugin aus experimental in siduction experimental ist eine gute Lösung.
Wer mit Debian vertraut ist, und eine bestimmte Snapshot Version haben möchte, kann die ja ohne Schwierigkeiten installieren.
@Lanzi: Wenn Du die stabile 2.4.1 Version haben möchtest, dann lade Dir digikam, digikam-data, kipi-plugins, kipi-plugins-common und showfoto in Version 2.4.1 und Deiner entsprechenden Architektur von snapshots in ein Verzeichnis und installiere mit dpkg -i *.deb
Holds sind zur Zeit nicht notwendig, solange Du nicht experimental oder siduction experimental in Deiner Sources.list hast, weil in Sid die nidrigere Version 1.9.0 aktuell ist.
Ich habe nun diese Version hier laufen und bin zufrieden damit.
Viele Grüße,
Holger
Moin,
ich will ja nicht draengeln, aber bisher ist noch nichts von Digikam in experimental zusehen.
;-)
Tschuess
Henning
Hallo Henning,
nu drängel mal den Alf nich so, nech ... :D
Die 2.4.1 Version aus Snapshot ist besser, weil es damit keine Schwierigkeiten beim Fotoimport von Kameras gibt. Bei Version 2.5.0 und 2.6.0 Beta1 musste ich dafür den Kartenleser bemühen.
Viele Grüße,
Holger
Tu ich ja nicht ....... jedenfalls nicht wirklich ;-)
@henning: Nur weil Du noch nichts siehst, heisst nicht, dass ich noch nichts gemacht habe. Macht nichts, die Diskussion hatte ich bisher mit allen meinen Arbeitgebern :twisted: Glaub mir, Du hättest das Ergebnis meiner Arbeit noch nicht öffentlich haben wollen ;). Stand jetzt ist, dass ich jetzt den Prozess so langsam im Griff habe, ein paar Tests müssen noch folgen.
Holgerw: Wir sollten noch mal das für und wieder Snapshot vs. experimental unter die Lupe nehmen. Ich habe es bisher bei jeder Namensdiskussion, sei es Distributionsname, Pakete etc immer wieder auf den Tisch gebracht. so auch hier: Namen sind Schall und Rauch. Wenn wir uns für Snapshots entscheiden sollten, dann sollten wir es für eine klare Trennung auch so nennen. Dann wäre ich für ein Snapshots-Repo, die Trennung ist sauberer. Da könnte man natürlich dann ohne Rücksicht auf Verluste die jeweiligen Snapshots reinjagen. Ihr, die ihr das benutzt, müsstet dann nur sagen, was brauchbar ist. Ich bin da nicht im Thema.
Moin,
kool bleiben bitte , es beschwert sich ja niemand. Es ist fertig wenn's fertig ist und nicht frueher ;-) Der Post von Agaida hoerte sich eher nach "ist ein klacks und fertig" an. Deshalb meine Frage. Also mal ganz in Ruhe fertig machen.
Tschuess
Henning
Nur mal so kurz angedacht:
Wir hätten eine wirklich riesige 'Marktlücke' im ganzen Debian Bereich, wenn wir Kde-4.8.x selbst bauen und zur Verfügung stellen könnten.
---
Natürlich müssten wir einige Debian-unstable Pakete als nicht parallel zu installieren markieren: Genau die Pakete, die jetzt schon die Transition von Kde-4.7.4 von experimental nach unstable verhindern, also hauptächlich Berechnungs-Libs aus dem Scientific-Bereich ...
---
- Wie schwer wäre das? (ca drei Pakete umbenennen von 4.7 nach 4.8 ? )
- Hätten wir die Server und Compile Power?
Rechenpower haben wir lang und schmutzig. In diesem Fall zum Glück nicht die Manpower.
KDE neu kompilieren lassen ist nicht das Problem, ich hab gehört User von Gentoo machen das öfter. Die Frage ist: Will man das wirklich?
Wenn sich jemand berufen fühlt, KDE zu packen, dann wäre der logische Weg, das in debian zu tun. Die Jungs freuen sich über jede ernst gemeinte und vor allem fachkundige Hilfe. Einen Weg, wie ihn Ubuntu geht, kann ich nicht wirklich empfehlen. Ich würde nur allzugern einen stabilen KDE-Desktop haben.
@ralul:
Das wär in der Tat ein definitives Killerfeature von siduction... Richtig cool!
Die Idee hatte ich auch schon.
Aber selbst bei den KDE Snapshots dauert das immer recht lange, so dass ich mal vermute, dass es einiges an Aufwand ist.
KDE packen ist recht einfach und dauert auch gar nicht lange. Die Jungs bei Arch machen es vor. Die Kunst liegt darin, dass wir das Rad neu erfinden müssten. Das nutzt keiner Seite.
@agaida, Du irrst Dich hier wahrscheinlich.
Der Grund, dass es kein neueres Kde-4.8 und vorher schon kein Kde-4.7.4 gibt in Debian unstable sind die Libs, die wahrscheinlich von den Universitäten kommen, im Scientific Bereich. So habe ich die Mailingliste mit meinem kleinen English jedenfalls verstanden.
Wenn ich Recht habe, dass der Kde Stau bei Debian an den Sponsoren hängt - Sponsoren hier gemeint als Organisationen, die Entwickler abstellen, zB den jetzigen Debian Leader - dann könnte es sogar sein, dass sich Debian Maintainer, die Kde pushen wollen, für ein solches Projekt interessieren könnten: Eine Kde Spielwiese für reine Desktop Nutzer ...
Also, ich könnte mir mindestens vorstellen, dass wir sehr guten Support kriegen würden für solch eine Anstrengung in den entsprechenden Debian IRC Channeln, denn unser Projekt ist ja durch Devil als sehr Debian treu bekannt dort.
[edit] gerade Deinen Beitrag gesehen: "Rad neu erfinden"
Wieso, wir könnten die git-Repos der Debian Kde Maintainer plündern und nur eben für Kde-4.8 anpassen.
Einen problematischen Bereich für ein eigenes siduction Kde sehe ich nur:
Die Kdepim Nutzung
Eine Transition vom alten ins neuere Kdepim wäre sehr verantwortungsvoll und Risiko reich, weil wir mit wertvollen Nutzerdaten hantieren, die kaputt gehen könnten. Eine einfachst Lösung wäre zB eine Bedingung:
!Kmail
Da hätten dann Leute, wie Holgerw das Nachsehen und sauer :(
Wenn wir kde in einem extra Repo anbieten, könnten Kmail User halt später dazu kommen, wenn auch der kdepim Bereich getestet ist ....
Nebenbei:
Ein eigenes Kde Repo würde uns auch unabhängig machen von dem bevorstehenden Big-Freeze ähnlich wie beim Linux Kernel.
Ein anderer Vorschlag: Wir lassen es alles so, wie es ist und warten halt ab. Wir haben uns dazu entschlossen (ganz zufällig natürlich) sid als Basis zu nehmen. Damit haben wir auch den "debian way" übernommen: Abwarten und Tee trinken. Und wenn der mal knapp wird, dann einfach neuen kaufen.
Die Schwierigkeiten mit KDEPim kann ich zumindest nicht nachvollziehen, andere Distributionen auch nicht. Wenn in einer Software Fehler sind, dann setzt man, so möglich, alles daran, dass die Fehler gefixt werden. Der debian-way ist da anders: Laut weinen und versuchen, längst verrottete tote Pferde einzubauen. Vielleicht sehe ich das auch nur ein wenig zu locker. KDE 4.8 ist ja schon eine Weile releast, pünktlich zu KDE 4.9 or whatever wird dann KDE 4.8 in Sid erscheinen. Was solls.
Nicht nur der Aufwand, es ist auch nicht ganz so trivial wie einfach mal ein Debian-Paket zu bauen. Das können wir derzeit und absehbar nicht stemmen.
greetz
devil
Hm, wir sind ja bei kdenext schon auf "experimental".
Auch wenn ich sehr dafür bin dass auch neuere Pakete die ewig in Debian hängenbleiben jetzt , wie mit "kdenext", angeboten werden so halte ich es ebenfalls vom Aufwand nicht wirklich machbar dass jeder sein neues Lieblingspaket ins Repo bekommt.
Da blickt dann nach ner Weile keiner mehr durch diesen Distro-Mix wirklich durch.
Wenn man halt wirklich dringend ein spezielles "Feature" einer Software braucht muss man es sich halt doch selbst (z.B. aus testing, experimental oder sogar incoming) besorgen und auf eigene Verantwortung installieren oder gegebenenfalls sogar selbst kompilieren.
So mach ichs bisher und ich weiss auch dann immer wer für den daraus entstehenden Unfug verantwortlich ist :P
Meine Meinung dazu.
Grüße
Reiner
@RainerS: In diesem Fall ist "experimental" ausentwickelt. Die Jungens warten nur noch auf einen Slot und den ein oder anderen Blocker. Oder lassen es ganz, wenn die Blocker für 4.8 weg sind, was wesentlich sinnvoller wäre. Von daher ist experimental != experimental und der Schritt zu 4.7.4 auch auf ISO war zu vertreten.
Ich bin wirklich kein Kind von Traurigkeit, was so was angeht. Allerdings stellt sich wirklich die reine Sinnfrage. Privat muss ich sagen, dass KDE 4.8 eine hübsche Sache ist, ich benutze es gerne, wie auch 4.7.4 - nur ich sehe den absoluten Zwang zum Umstieg nicht wirklich. Wenn es mal da ist, werde ich mich freuen.
Diese Versionitis geht mir so oder so ein wenig auf den Sack, größtenteils merke ich nicht einmal an den Funktionen, mit welcher Version ich arbeite. Beste Beispiele sind da Chromium oder aber Firefox, wo ich schon gar nicht mehr auf die Nummern schaue. Ich bin nur ab und zu mal etwas erstaunt, wie sich die Zahlen weiterentwickeln ...
agaida sagte: "Wir lassen es alles so, wie es ist und warten halt ab."
Da können wir halt wirklich _lange_ warten im Fall Kde: Es ist geplant "vielleicht" Kde-4.7.4 ins nächste Debian stable zu bekommen. Das würde heissen, dass sich mindestens ein Jahr lang nichts tun wird!
@ralul: Du bist eigentlich schon lange genug dabei, um zu wissen, wie es läuft: Richtig geraten - 4.7.4 geht nach sid, irgendwann - und irgendwann wird dann 4.8 in experimental erscheinen. Ist doch klasse. Und wenn die Pakete in ihrer Gesamtheit so stabil sind, dass wir die ohne schlechtes Gewissen auf unsere User loslassen können, dann werden wir das nach reiflicher Überlegung tun.
Hmm, dann bin ich falsch in meinem Impetus: Weil in einer Mailingliste gesagt wurde, dass das Releaseziel 4.7.4 ist, und weil ich weiss, dass das für Debian-sid ein Jahr lang Stillstand heisst, bin ich davon ausgegangen, dass die Debian Maintainer kein Interesse haben würden Kde-4.8 zu bauen.
Woher weisst du, dass Kde-4.8 nach experimental kommen wird?
In unserer schnellebigen Zeit kommen Mailinglisten gleich nach snailmail. Und da auf 4.7.4 eigentlich kaum was passiert ist in den letzten Wochen (die Paketänderungen halten sich in sehr eng definierten Grenzen) und das qt-kde-Team eifrig arbeitet, gehe ich davon aus, dass die in den letzten Wochen nicht untätig waren.Nebenbei tauscht man so die eine oder andere Zeile mit Entwicklern, die grade am packen sind.
Daraus habe ich einfach mal geschlussfolgert, dass die Jungs was für eine Transition haben, wenn sie einen Slot bekommen und die Blocker weg sind. So ganz nebenbei unterhält man sich auch ab und zu mal mit diesem und jenem ... Und wir reden hier ja wirklich von experimental und sid. Ob 4.8 in stable landet, ist mir so was von Wurst, das kann sich keiner vorstellen. Eine DE in stable ist so oder so kurz nach dem Erscheinen für unsere Zielgruppe einfach nur obsolet und irrelevant.
EDIT: Und dass 4.8 in experimental aufschlagen wird, ist so sicher wie das Amen in der Kirche. Im doppelten Sinne. Man weiss, dass es kommen wird, wenn auch nicht genau wann. Und auch in beiden Fällen: Viel zu spät!
Hallo Alf,
ein extra Snapshot Repo wäre sicher ein zusätzlicher Luxus, aber ehrlich gesagt ist es doch nicht allzu schwer, gerade bei digikam sich die passenden 5 Pakete aus den Snapshots herunter zu laden und mit dpkg zu installieren.
Dass nur wenige Maintainer für Blockaden beim KDE Packen des KDE Debian Teams verantwortlich sind, macht mich nun doch sauer. Für den ambitionierten Anwender ist es nicht nachvollziehbar, dass unter einem nicht rollenden Release wie OpenSUSE quasi parallel zur Arbeit des KDE Entwicklerteams ein aktuelles OpenSUSE Community KDE Repo gepflegt wird, die bauen das einfach mal so und es funktioniert und bei Debian Sid als rollendem Release geht es nicht, weil einige Maintainer nicht daran interessiert sind, zeitnah den Nutzern das zu bieten, was die Projektgruppen freier Software liefern.
Damit meine ich NICHT siduction oder das KDE Debian Team, die leiden darunter ja auch, wie ich an anderer Stelle in einem Beitrag von Devil zum Wert von KDE in Debian gelesen habe.
Viele Grüße,
Holger
Einen kleinen Fortschritt gibs zu vermelden. Die libarchive Transition ist fast beendet.
http://release.debian.org/transitions/html/libarchive.html
greetz
devil
@holgerw: snaps sollte eigentlich keinen zusätzlichen Luxus bieten, sondern den Prozess einfach sauber machen. Wenn Du auf die Liste der geblockten KDE-Pakete schaust, wirst Du verstehen, was ich meine (digikam, kipiplugins sind momentan auf der Liste, die rot ist und gestern wieder ein Stück kleiner wurde). Wenn also digikam regulär gebaut wird, würde das mit Snaps überschneidungen geben. Nicht schön.
Auch wenn ich den Frust über debian nachvollziehen kann - ich haue ja auch bei jeder passenden und auch unpassenden Gelegenheit auf den Buben rum - Du machst da einen kleinen Denkfehler. sid und testing sind *keine* rollenden Distributionen. Auch wenn einige Leute das gerne so sagen und einige Merkmale einer rollenden Distribution durchaus gegeben sind.
Diese Diskussion kommt immer zu Freezes wieder auf: In kurzen Worten - wie nennt man eine rollende Distribution, wenn sie mal nicht rollt. Laut debian-Definition sind Sid und Testing Entwicklungszweige, die dazu dienen, das nächste Stable zu basteln. Das das Zeug den Namen nicht ändert und in Zeiten in denen nicht Eiszeit angesagt ist, auch ganz gut rollt, ist ein netter Nebeneffekt. Mehr nicht. Deshalb geisterte auc die Idee von CUT vor einiger Zeit duch Mailing-Listen. Das unterbrechungsfrei nutzbare Testing würde einer echten rollenden Distribution wesentlich näher kommen, als der bisherige Stand.
Quote from: "agaida"
[...]
Diese Diskussion kommt immer zu Freezes wieder auf: In kurzen Worten - wie nennt man eine rollende Distribution, wenn sie mal nicht rollt. Laut debian-Definition sind Sid und Testing Entwicklungszweige, die dazu dienen, das nächste Stable zu basteln. Das das Zeug den Namen nicht ändert und in Zeiten in denen nicht Eiszeit angesagt ist, auch ganz gut rollt, ist ein netter Nebeneffekt. Mehr nicht. Deshalb geisterte auc die Idee von CUT vor einiger Zeit duch Mailing-Listen. Das unterbrechungsfrei nutzbare Testing würde einer echten rollenden Distribution wesentlich näher kommen, als der bisherige Stand.
..wie ist denn der aktuelle Stand von CUT, ohne jetzt ellenlange englischsprachige Debianseiten lesen zu müssen? Wäre halt schön wenn ein "echtes RR" in Debian in naher Zukunft Wirklichkeit werden würde ***träum***
Quote
sid und testing sind *keine* rollenden Distributionen.
Sie sind keine Distributionen. Punkt.
greetz
devil
Auch wenn man beim Quoten knapp sein soll, nichts anderes hab ich geschriebeb. :twisted:
Quote
... sid und testing sind *keine* rollenden Distributionen. Auch wenn einige Leute das gerne so sagen und einige Merkmale einer rollenden Distribution durchaus gegeben sind ...
Manchmal ist auch der Kontext wichtig.
Quote
... Laut debian-Definition sind Sid und Testing Entwicklungszweige, die dazu dienen, das nächste Stable zu basteln ...
Lass mich doch knapp sein :)
greetz
devil
Wenn sich menschen dazu entschlißen, selber kde zu bauen, dann bitte sprecht mit den KDE Mantainern! weil diese Arbeit sollte nicht doppelt gemacht werden, andererseits wäre es wohl sehr wahrscheinlich, das wir dann dauerhaft KDE selber bauen müssten, weil das ganze schnell inkompatibel wird. Was aus meinen Augen unbedingt zu vermeinden ist, weil dann sind wir nicht mehr debian sid komplatibel - eines der wichtigsten Featuers in meinen Augen für diese Distri. Btw. im debian kde git liegen schon einige Sachen in kde 4.8 vor...
Zur Trasistion von KDE4.7: es liegt nicht daran, das einige KDE Mantainer pennen oder ihre Pakete nicht fertig bekommen, sondern daran, das die Transistion auf andere waren muss z.B. OpenCV (digikam etc.) u.a. Jedoch kommen diese Transistions nicht vom Fleck, weil dort einige Mantainer schlafen oder einfahc was anderes zu tun haben...
Ob nun KDE4.7. oder KDE4.8 in wheezy Einzug halten wird, darüber streiten sich die Geister :) Es gibt Stimmen die das eine behaupten die Anderen das Andere. Im IRC wurde schon öfters versucht eine einheitliche Front nach außen zu vertreten, was aber nicht wirklich klappt :) Wir werden also einfach weiter Glaskugel lesen oder einfach das ganze auf uns zukommen lassen.
@hefee: Eine kleine Korrektur dazu hätte ich: Man wird durch den Eigenbau von KDE nicht zwangsläufig zu debian sid inkompatibel. Man wird eventuell oder sogar wahrscheinlich inkompatibel zu bestimmten Paketen, weil kein Mensch,der nur sein eigenes Problem lösen will, auf die Idee kommen wird. Symbole zu schubsen. Ersthaft selbst bauen will hier glaube ich wirklich keiner.
Das macht keinerlei Sinn, eine direkte Beteiligung in debian wäre dann sinnvoller. Ich gebe auch zu, eine Beteiligung bei debian weder jetzt oder noch momentan absebar eine Option für mich ist. Konsumieren und eventuelle Fehler melden muss an dieser Stelle reichen.
Hallo,
wir brauchen also einen Ralf Nolden für das aktuelle KDE :-)
Kennt den noch jemand? Ich fand es damals sehr schön, KDE3 Pakete zu haben, die sich einigermaßen sauber über Ralfs Repo auf Debian installieren ließen.
Viele Grüße,
Holger
@holgerw
nicht dass wir uns falsch verstehen: Wenn jemand von uns auf die Idee kommt, KDE-Pakete zu fixen und auch über unser Repo zur Verfügung zu stellen, wird das im allgemeinen auch funktionieren, das ist nicht der Punkt.
Was ich so lapidar mit Symbole schubsen bezeichnet habe, ist der Vorgang, die generierten Symbole so anzupassen, dass sie eventuell zutreffender und allgemeiner sind und damit mit einer etwas weiter gehaltenen Anzahl Versionen funktionieren. Ist eine Scheiss-Arbeit, vor allem aber auch fehlerträchtig. Bin ich auf solche Überlegungen nicht angewiesen, dann lösche ich den Kram halt und lasse ihn generieren ;) Nicht die feine englische Art, weil die abseits vom eigenen Rechner auch wieder Seiteneffekte hervorrufen könnte. Bei einer Distribution wie debian mit der Anzahl Pakete und Architekturen bin ich mit diesem Vorgehen aber verraten und verkauft.
Hallo Alf,
ist schon klar, und falls ich meine, etwas vielleicht falsch zu verstehen, frage ich halt nach :-)
Und was ich nicht falsch verstanden wissen möchte: Hier machen die siduction Entwickler ganz tolle Arbeit. Und wenn ich mich über Fehlfunktionalität oder anderes echauffiere, was in meinen Augen Mängel hat, dann ist das keinesfalls mit der Forderung an Euch verbunden, dass doch mal bald gefälligst zu korrigieren.
Was digikam angeht, bin ich jetzt mit den 2.4.1 Paketen sehr zufrieden, mein Vater auch.
Viele Grüße,
Holger
Das Blöde ist ja an so einem Unterfangen wie dem unsrigen, dass es recht große Schnittmengen zwischen Entwicklern und Anwendern gibt. Wir benutzen unser favorisiertes Flavour auch selbst. Und deshalb haben die meisten Wünsche nach Software oder der Behebung eines Fehlers auch einen nicht zu unterschätzenden Einfluss auf die Bearbeitung. ;)
Quote from: "agaida"... die generierten Symbole so anzupassen, dass sie eventuell zutreffender und allgemeiner sind und damit mit einer etwas weiter gehaltenen Anzahl Versionen funktionieren. Ist eine Scheiss-Arbeit, vor allem aber auch fehlerträchtig
Meine Idee war, wenn es einen solchen Debian Stau gibt, das die Debian-Kde-Maintainer frustriert sind, sie froh wären eine freie Spielwiese zu haben, mit jeder Menge von Testusern umsonst anbei. Mein geheimer Wunsch war also, diejenigen direkt zu uns hier einzuladen ....
Quote from: "ralul"Quote from: "agaida"... die generierten Symbole so anzupassen, dass sie eventuell zutreffender und allgemeiner sind und damit mit einer etwas weiter gehaltenen Anzahl Versionen funktionieren. Ist eine Scheiss-Arbeit, vor allem aber auch fehlerträchtig
Meine Idee war, wenn es einen solchen Debian Stau gibt, das die Debian-Kde-Maintainer frustriert sind, sie froh wären eine freie Spielwiese zu haben, mit jeder Menge von Testusern umsonst anbei. Meine geheimer Wunsch war also, diejenigen direkt zu uns hier einzuladen ....
Hallo Ralul,
Deinen Vorschlag finde ich sehr gut.
Viele Grüße,
Holger
Ich habe endlich mal eine genauere Auskunft gefunden, wie es mit Kde in Debian weiter gehen soll. Modestas Vainius:
QuoteThe plan is to ship wheezy with KDE 4.8.x where x is the
last in the series (probably 4.8.4).
If I were you I wouldn't expect anything news-worthy to happen on the KDE 4.8 front until KDE 4.7.4 gets to testing (not that it means something will happen soon after). KDE transitions typically take a month or two to start...
Also Kde-4.8 kommt doch. Allerdings kann es dauern...
Schätzungsweise mindestens 3-4 Wochen (wenn keine Transitions blocken)
greetz
devil
Sehr optimistisch!
Das Zitat war:
"(not that it means something will happen soon after)"
So, jetzt ist es geschehen. Wir haben ein neues Repo experimental-snapshots. Darin befinden sich momentan ganze zwei Pakete, digikam und digikam-data. Die ganzen Abhängigkeiten sind jetzt regulär in Sid, was die Sache natürlich erleichtert. ;) Soweit ich das beurteilen kann, macht digikam seine Aufgabe mit 2.6 beta1 recht gut, warten wir mal, was die grad freigegebene beta2 so alles Nettes kann. Die Einbindung von Experimental-Snapshots findet sich auf packages.siduction.org. Anfang der Woche würde ich das auch auf die Mirrors verteilen, wenn das auf Zustimmung stößt.
Hi agaida,
frisch eingebunden, Update gemacht, Upgrade gemacht, funktioniert alles 1a.
[Sa, 17.03.2012, 21:22:10]
[stell @ shangrila:~]% uname -a
Linux shangrila 3.2-10.towo.1-siduction-amd64 #1 SMP PREEMPT Tue Mar 13 16:35:01 UTC 2012 x86_64 GNU/Linux
Hallo Alf,
vielen Dank für Deine Arbeit, ich werde mir heute mal das aktuelle digikam aus experimental-snapshots installieren.
Du schreibst, im siduction/experimental-snapshots seien nur zwei Pakete digikam und digikam-data, und der Rest sei nun in Debian Sid. Die kipi-plugins in Sid sind aber immer noch in Version 1.9.0.
Das heißt doch aber, dass ich ohne die regulären Debian Experimental Quellen, in denen digikam 2.6.0beta1 ja eh drin ist, gar nicht an die aktuellen kipi-plugins 2.6.0beta1 komme. Oder stehe ich da gerade etwas auf dem Schlauch? :-)
Leider ist http://packages.siduction.org momentan nicht erreichbar, sonst würde ich mal nachschauen.
Viele Grüße,
Holger
Gemach. Kipi-plugins und Kipi-plugins-common sind jetzt auch dabei.
Hallo Alf,
danke, dass nun die kipi Pakete auch dabei sind.
QuoteDarin befinden sich momentan ganze zwei Pakete, digikam und digikam-data. Die ganzen Abhängigkeiten sind jetzt regulär in Sid, was die Sache natürlich erleichtert.
Das hatte ich so verstanden, dass es bei den zwei Paketen vorerst bleiben soll :-)
Viele Grüße,
Holger
Ich war mal so frei, erst mal die Version ohne kipi ein wenig zu testen. Da kipi-Pakete nicht zwingend sind, habe ich mir so gedacht, was ich noch nicht verteile, muss ich im Zweifel auch nicht wieder entfernen. ;)
Hmm, eine Frage dazu:
Kommt dieses Repo auch auf ftp.spline ? oder bleibt es ausschlieslich auf packages.siduction.org ?
Grüße
Reiner
momentan liegt es nur auf p.s.o. Imho spricht aber nichts dagegen, das auch weiterzuverteilen. Wichtig war erst mal nur, dass der Gedanke, so was zu bauen, nicht generell schwachsinnig und das dieses Konstrukt wartbar ist.
Es schaut so aus, dass beide Punkte zur Zufriedenheit erfüllt sind. Von mir aus können wir das so auf die Spiegel packen, wenn sich das bewährt.
OK, dann warte ich noch ein wenig so dass ich meine sources.list bzw. apt-cacher-ng nicht allzu umbauen muss 8)
Grüße
Reiner
@Agaida: Dank Dir! Gute Arbeit!