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