STBR

Jakub Bogusz qboosh w pld-linux.org
Nie, 4 Wrz 2005, 11:07:48 CEST


On Sun, Sep 04, 2005 at 02:28:18AM +0200, Jakub Piotr Cłapa wrote:
> Arkadiusz Miskiewicz wrote:
> > On Saturday 03 of September 2005 13:43, Patrys :: Patryk Zawadzki wrote:
> >>>Przecież nowy dbus nie jest jeszcze gotowy. Nie ma na amd64. Nie puszczać
> >>>tego.
> >>
> >>Można szczegóły prosić? W ready widzę już zbudowane paczki i zależności
> >>od nowego dbus, który mi jest potrzebny. Release jest pełny, więc proszę
> >>o dokładne info odnośnie kończenia tej paczki.
> > 
> > W ready nie ma paczki dbusowej dla amd64 przecież. Nie buduje się po prostu 
> > przez mono, które to najpierw trzeba zwalczyć (dość opornie to idzie; po 
> > drodze bug w rpmie, a dokładniej zły libmagic itp).
> > 
> >>Czy problem jest u nas (dorobić coś w specu - mogę się tym zająć, jeśli
> >>dostanę wjazd na jakiś AMD64), czy w samym dbusie i czekamy na autorów?
> > 
> > W mono :) Zerknij na buildlogi.
> 
> To może zrezygnować ze wspierania dbus-mono do czasu rozwiązania 
> problemu? W starym dbusie (tym, którego teraz mamy) było wsparcie dla 
> mono?

Na ftp jest. I:

SPECS/gfax.spec:BuildRequires:  dotnet-dbus-sharp-devel
SPECS/muine.spec:BuildRequires: dotnet-dbus-sharp-devel >= 0.21
SPECS/tomboy.spec:BuildRequires:        dotnet-dbus-sharp-devel

> I czemu działało?

Bo było stare mono.
Teraz nie da się zainstalować nowego monodoc, bo się mono-tools nie
kompiluje.
Do tego nowe mono:
- nie działa na sparcu (teoretycznie powinno, ale po poprawieniu błędu
  kompilacji libgc mono sypie się z SIGSEGV)
- nie buduje się na alphie, są jakieś wyścigi (albo w samym systemie
  budowania, albo główny proces mint kończy działanie przed potomkami)
  i próbuje odczytywać pliki przed ich utworzeniem;
  podobny efekt ponoć występuje także na x86 z NPTL przy niektórych
  wersjach jądra(?)

Czyli nadal nie gotowe.


-- 
Jakub Bogusz    http://qboosh.cs.net.pl/



Więcej informacji o liście dyskusyjnej pld-devel-pl