[RISOLTO] libwnck22 dipende erroneamente da libcompizconfig0

[telperion]

Su Ubuntu Hardy Heron il pacchetto   

libwnck22
Window Navigator Construction Kit - runtime files
A library to use for writing pagers and task lists.
ha erroneamente come dipendenza libcompizconfig0
che ovviamente non c'entra nulla col suddetto pacchetto
e crea problemi (dovendo tenere installato un pacchetto che è in palese conflitto
con le librerie compiz compilate da sorgenti).

mc@mc-desktop:~$ apt-cache depends libwnck22
...
  Dipende: libcompizconfig0
...

Ovviamente libcompizconfig (che serve a compiz ccsm e plugin)
non c'entra nulla col pacchetto libwnck22

mc@mc-desktop:~$ apt-cache rdepends libcompizconfig0
libcompizconfig0
Reverse Depends:
  python-compizconfig
  libcompizconfig-backend-kconfig
  libwnck22
  libcompizconfig0-dev
  compizconfig-backend-kconfig
  compizconfig-backend-gconf
  compiz-core
  compiz

Non ho accesso/account al launchpad
se qualcuno vuole segnalare il bug.

Spero in una rapida correzione.

[lex79]

Mi dici tutti i passi che hai fatto per scoprire il bug? Così cerco di segnalarlo

[telperion]

Mi dici tutti i passi che hai fatto per scoprire il bug? Così cerco di segnalarlo

Sono scritti li:

Codice:

apt-cache depends libwnck22

ha come dipendenza tra i vari pacchetti  libcompizconfig0 che è un pacchetto che non c'entra nulla

La prova incrociata (reverse depend):

Codice:

apt-cache rdepends libcompizconfig0

dice infatti che libcompizconfig0 è una dipendenza di 7 pacchetti compiz (corretto)
e   libwnck22 che invece non c'entra nulla.


Praticamente installando libwnck22 ti viene installato automaticamente anche libcompizconfig0
che non è assolutamente necessario a  libwnck22.

Ad esempio su Gutsy le dipendenze sono
http://packages.ubuntu.com/gutsy/libwnck22

[lex79]

In effetti lo si vede anche guardando le dipendenze del pacchetto libwnck22 in gutsy:
http://packages.ubuntu.com/gutsy/libwnck22
e in hardy:
http://packages.ubuntu.com/hardy/libwnck22
confrontandoli la differenza sta in quel pacchetto: libcompizconfig0
Lo segnalo, ciao

[DktrKranz]

La modifica è intenzionale:

Codice:

  * fixed bug (no LP-entry) in 02_expose_wm_keybindings.patch not checking for compiz-
    plugins scale and expo actually being loaded for the active effects-profile

[telperion]

La modifica è intenzionale:

Codice:

  * fixed bug (no LP-entry) in 02_expose_wm_keybindings.patch not checking for compiz-
    plugins scale and expo actually being loaded for the active effects-profile

Questo però genera dipendenze circolari.

Compilando Compiz da sorgenti
il relativo gtk-window-decorator
non si compila perchè:

Codice:

Executing make
/usr/bin/ld: warning: libcompizconfig.so.0, needed by /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libwnck-1.so, not found (try using -rpath or -rpath-link)

cioè libwnck-1.so (dipendenza di gtk-wd) non trova libcompizconfig.so.0 da cui dipende,
e quindi blocca la compilazione di Compiz.

Peccato che per compilare libcompizconfig sia necessario avere Compiz (da cui dipende) installato.

Risultato: è possibile compilare compiz solo disabilitando gtk-window-decorator.

Codice:

--gtk-disable

Situazione che si verifica esclusivamente su Hardy Heron.
Come se ne esce?

[DktrKranz]

Compilando da sorgenti non hai problemi di circolarità, installando libcompizconfig0-dev e lanciando ldconfig.real, non dovresti avere problemi.

[telperion]

Compilando da sorgenti non hai problemi di circolarità, installando libcompizconfig0-dev e lanciando ldconfig.real, non dovresti avere problemi.

Ma se io lo devo compilare da sorgenti compiz libcompizconfig ccsm eccetera,
non posso usare libcompizconfig  dei pacchetti Hardy che è diverso da quello nel git, mi sembra evidente.

libcompizconfig da pacchetto dovrebbe essere necessario
(come è sempre stato e come è nelle altre distribuzioni)
solo  se installi compiz da pacchetti,
altrimenti genera un casino.
Cioè io prima compilo compiz con il gtk che usa libcompizconfig del pacchetto,
poi compilo il mio libcompizconfig da git che và a sovrascrivere i file del pacchetto e magari è pure diverso.
Mi sembra una pessima soluzione.

Obbligare l'installazione del pacchetto libcompizconfig0
anche a chi non utilizza il compiz impacchettato nei repository,
non mi sembra una bella idea.
Mi sembra che crea solo problemi.
IMHO.
 

[lex79]

Hanno risposto
https://bugs.edge.launchpad.net/ubuntu/+source/libwnck/+bug/197489

[telperion]

Hanno risposto
https://bugs.edge.launchpad.net/ubuntu/+source/libwnck/+bug/197489

Intanto grazie per l'interessamento, i casini che comporta ho tentato di spiegarli,
sto lavorando ad un workaround per "bypassare" il tutto.
Inutile ripetere quello che ho già scritto sul perchè non è una buona soluzione.
Al primo cambio di ABI di compiz e le libcompizconfig (quella nel sistema generata con il vecchio compiz, e quella nuova da generare) non saranno allineate capiranno il perchè.

Per ora io faccio un divert della /usr/lib/libcompizconfig.so.0
compilo con lo script compiz senza GTK-WD (che ha le dipendeze circolari)
comiplo tutto il resto libcompizconfig ccsm plugin eccetera,
poi con la libcompizconfig compilata ( e quindi coerente)
ricompilo compiz con GTK-WD abilitato ed ho un sistema coerente.

Un bel casino però.
Meglio di cosi non riesco a spiegarlo.

[telperion]

Compilando da sorgenti non hai problemi di circolarità, installando libcompizconfig0-dev e lanciando ldconfig.real, non dovresti avere problemi.

installando libcompizconfig0-dev
mi fà installare compiz-core e compiz-dev,
mentre io compiz lo voglio compilare.

La vedi la circolarità introdotta?

[DktrKranz]

Al primo cambio di ABI di compiz e le libcompizconfig (quella nel sistema generata con il vecchio compiz, e quella nuova da generare) non saranno allineate capiranno il perchè.

Continuo a non vedere il problema. Un eventuale ABI break di ibcompizcommon non influisce più di tanto su libwnck per il semplice fatto che, in caso di SONAME bump di libcompizcommon (che non ha build-depends con libwnck), verrebbe assorbito con un semplice rebuild di libwnck per la transizione libcompizcommon0 -> libcompizcommon1.

installando libcompizconfig0-dev
mi fà installare compiz-core e compiz-dev,
mentre io compiz lo voglio compilare.

La vedi la circolarità introdotta?

No. I due build sono indipendenti, siccome libcompizconfig è un pacchetto sorgente separato da compiz.

[telperion]

Al primo cambio di ABI di compiz e le libcompizconfig (quella nel sistema generata con il vecchio compiz, e quella nuova da generare) non saranno allineate capiranno il perchè.

Continuo a non vedere il problema. Un eventuale ABI break di ibcompizcommon non influisce più di tanto su libwnck per il semplice fatto che, in caso di SONAME bump di libcompizcommon (che non ha build-depends con libwnck), verrebbe assorbito con un semplice rebuild di libwnck per la transizione libcompizcommon0 -> libcompizcommon1.

installando libcompizconfig0-dev
mi fà installare compiz-core e compiz-dev,
mentre io compiz lo voglio compilare.

La vedi la circolarità introdotta?

No. I due build sono indipendenti, siccome libcompizconfig è un pacchetto sorgente separato da compiz.

Abbi pazienza, ma compilo sta roba da anni e libcompizconfig se non hai compiz installato non si compila,
infatti, nel file cotrol del pacchetto il -dev dipende da compiz-dev.

Semplificando:

- scarico i sorgenti di Compiz per compilarlo:
- scompatto
- configurazione per gnome con gtk-window-decorator:

Codice:

./autogen.sh --prefix=/usr  --enable-gtk --disable-kde --enable-librsvg --disable-kde4 --disable-fuse --disable-kconfig

- make: errore

Codice:

    Executing make
    /usr/bin/ld: warning: libcompizconfig.so.0, needed by /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libwnck-1.so, not found (try using -rpath or -rpath-link)
    …
    …
    collect2: ld returned 1 exit status
    make[3]: *** [gtk-window-decorator] Error 1
    make[2]: *** [all-recursive] Error 1
    make[1]: *** [all-recursive] Error 1
    make: *** [all] Error 2

Compiz non si compila perchè  libwnck (necessaria al gtk-window-decorator) dipende ora da libcompizconfig.so.0 che non viene trovata.

Installo allora il pacchetto libcompizconfig0-dev ma questo si porta come dipendenze e li installa compiz-dev e compiz-core.
http://packages.ubuntu.com/hardy/libcompizconfig0-dev
http://packages.ubuntu.com/hardy/compiz-dev


Ora se ti sembra normale, (a me non lo sembra assolutamente: dipendenze circolari di brutto,
le due build ora sono collegate dal gtk-window-decorator di compiz per via della libwnck22)
allora non so che altro dirti.

Io il problema l'ho segnalato nel modo più esaustivo possibile.
Amen.

[DktrKranz]

Ora se ti sembra normale, (a me non lo sembra assolutamente: dipendenze circolari di brutto)
allora non so che altro dirti.

Domanda: libcompizcommon è parte integrante di compiz, prelevato da sorgenti? Se così fosse, la compilazione da sorgenti non può avvenire, come giustamente sostieni. Il problema è che in gutsy libcompizconfig è stato immesso in un pacchetto standalone, probabilmente per un problema analogo a questo. Il fatto è che questa fattispecie non è contemplabile ufficialmente in quanto il problema non si pone (è stato risolto sei mesi fa), difficilmente verrà risolto a meno che non si trovi una soluzione per il bug che ho quotato in precedenza. La strada più semplice che mi viene in mente è fare un fork di libwnck escludendo la modifica di macslow, in questo modo non avrai circolarità.

[gaspa]

io non vedo compiz-core tra le dipendenze di libcompizconfig0-dev...

[572]gaspa@saturnino:mantis$ apt-cache show libcompizconfig0-dev | grep Depends
Depends: compiz-dev, libcompizconfig0 (= 0.6.99+git20080215-0ubuntu1)

[gaspa]

io non vedo compiz-core tra le dipendenze di libcompizconfig0-dev...

perche' ovviamente e' tra quelle di compiz-dev... ok, ho detto una cavolata.

[telperion]

Domanda: libcompizcommon è parte integrante di compiz, prelevato da sorgenti? Se così fosse, la compilazione da sorgenti non può avvenire, come giustamente sostieni. Il problema è che in gutsy libcompizconfig è stato immesso in un pacchetto standalone, probabilmente per un problema analogo a questo. Il fatto è che questa fattispecie non è contemplabile ufficialmente in quanto il problema non si pone (è stato risolto sei mesi fa), difficilmente verrà risolto a meno che non si trovi una soluzione per il bug che ho quotato in precedenza. La strada più semplice che mi viene in mente è fare un fork di libwnck escludendo la modifica di macslow, in questo modo non avrai circolarità.

libcompizconfig è una libreria a se (o pacchetto) che serve sostanzialmente a collegare compiz al ccsm.
http://gitweb.opencompositing.org/?p=fusion/compizconfig/libcompizconfig;a=summary


Per compilare libcompizconfig (tutto da sorgente, oppure gli equivalenti  pacchetti  lib e -dev)
è necessario avere compiz (compiz-dev) installato, altrimenti non si compila
[compiz not found]

Compiz non è (non e mai stato) dipendente da libcompizconfig.
Infatti puo funzionare il core con i relativi plugin di base senza libcompizconfig e senza ccsm, tramite gfconf come era in origine.

Ricordo che compiz sorgente è core + plugin base + gtk wd + kde wd + kde4 wd.

http://gitweb.opencompositing.org/?p=compiz;a=summary

e la compilazione avviene configurano che moduli compilare esempio:

Codice:

./autogen.sh --prefix=/usr  --enable-gtk --disable-kde --enable-librsvg --disable-kde4 --disable-fuse --disable-kconfig

Ora da una settimana, prima era tutto a posto,
facendo dipendere libwnck22  da  libcompizconfig0,
si è creata la situazione che, dipendendo il gtk-window-decorator da libwnck22 e quindi ora anche da libcompizconfig0,
si è creata la circolarità, che non esiste nelle Ubuntu precedenti e neppure su Gentoo Archlinux e Debian sid, che infattti hanno tutti libwnck NON dipendente da libcompizconfig.

Io ho aggirato il problema cosi:

- compilo Compiz senza il gtk-window-decorator (evitando cosi l'incrocio)
- compilo libcompizconfig (con compiz installato compila perfettamente) e tutti gli altri componenti di Fusion
- ricompilo compiz con il gtk-window-decorator attivato (a questo punto libcompizconfig è installata e non crea problemi)

però il problema di incrocio tra gtk-window-decorator di compiz e libcompizconfig c'è.

Probabilmente non lo riscontra il sistema di build che produce compiz e i decoratori gtk kde e kde4 in diverse passate,
ma non sapendo come avviene è solo una ipotesi.

Comunque la situazione è diventata cosi dalla scorsa settimana, prima nessun problema.



 

[telperion]

Codice:

--- libwnck-2.22.0.orig/debian/changelog
+++ libwnck-2.22.0/debian/changelog
@@ -0,0 +1,708 @@
+libwnck (2.22.0-0ubuntu3) hardy; urgency=low
+
+  * debian/control.in:
+    - don't build using libcompizconfig

come volevasi dimostrare.

[Superpiffer]

ci è voluto un mese ma alla fine se ne sono accorti...