Damien: > If we can get pre-integration versions of the appropriate packages > we can install them onto the build machines. I did that this build > - used the b85 Xorg packages, and pre-integration versions of SUNWsqlite3.
However you want to work it out is okay with me. I just wanted to make sure that the RE team was aware of the issue, and the need to build the vermillion we plan to integrate into Nevada with the updated HAL. This will obviously require some extra work since the HAL changes are going in late into build 87. Artem is on the cc:list, so hopefully he can respond about whether it would be possible to provide us with updated x86 and Sparc packages so we can update our build machines to use them. Since this change will likely mean that people won't be able to use vermillion-devel builds with Nevada builds older than build 87, then we probably also need to highlight this in the release announcement. Brian > ----- Original Message ----- > From: Brian Cameron <Brian.Cameron at Sun.COM> > Date: Friday, March 14, 2008 7:36 pm > Subject: Re: [jds-review] question about CR6674505 > To: Ghee Teo <Ghee.Teo at Sun.COM> > Cc: JDS Dev <jds-dev at sun.com>, jds-review at opensolaris.org, Robert > Kinsella <Robert.Kinsella at Sun.COM>, gnome222-arc <gnome222-arc at > sun.com>, Alvaro Lopez Ortega <alvaro at sun.com>, Peng Patrick Gu > <Patrick.Gu at Sun.COM>, Artem Kachitchkine <Artem.Kachitchkin at Sun.COM>, > Jedy Wang <Jedy.Wang at Sun.COM> > > >> Ghee/GNOME 2.22 ARC and RE teams >> >>> We need those sparc and x86 packages more than just for tests. >>> I am sure Damien would like to put those packages on SDLC together >> with >>> our vermillion devel packages >>> so that the GNOME 2.22 can be tried out before integration into WOS >> for >>> Build 88 (according to current schedule). >> Note that normally the JDS RE team builds with Nevada build-2. If these >> canges go into Nevada build 87, and since we plan to integrate build 88 >> into Nevada, this means that we will need to coordinate with JDS RE to >> make sure we build vermillion build 88 with Nevada build 87. >> Alternatively, we could also build with an older build of Nevada and >> just hack the build machines to have the updated libhal.so* binaries. >> >> I understand this should be possible if we coordinate in advance with >> the JDS RE team. I think that adding these features is important enough >> that we would want to do this. >> >> Otherwise, these features would be broken in build 88, but then fixed >> in build 89, when we would build with Nevada build 87. Not sure if this >> would be a big problem or not. >> >> Brian >> >> >>> Robert Kinsella wrote: >>>> Hi Artem, >>>> I installed the new >>>> - /usr/lib/libhal.so.1.0.0 from >>>> >> /net/aja.sfbay/export0/tamarack/nv-hal-ps/proto/root_i386/usr/lib/libhal.so.1.0.0, >> >> >>>> - Having been removed, I put back the original >>>> /usr/lib/gio/modules/libgiohal-volume-monitor.so file and rebooted. >>>> >>>> 1. Login is ok. >>>> 2. Nautilus is functional. >>>> 3. inserted a data cd, nautilus drew new CD icon on desktop and >>>> launched 2x nautilus windows showing cd contents. >>>> 4. double clicking on CD icon on desktop nautilus cored and >>>> gnome-mount cored >>>> pstacks at:- >>>> >> /net/jdsserv.ireland/scratch/month/rk99157/pstacks_ver86/insertcd_click_on_data_cd_icon.txt >> >> >>>> >>>> >>>> 5. right clicking on desktop icon, select eject - cd was >> successfully >>>> ejected >>>> >>>> 6. Inserted Audio cd - pop up dialog stating unable to mount cd >>>> appeared - sound juicer launched - successfully played cd. >>>> - the eject button in sound juicer is greyed out. >>>> right click on audio cd in 'places' window in nautilus, select >> eject >>>> functioned. >>>> >>>> 7. file, connect to server, setup ftp connect to server, nautilus >>>> crashes on connection attempt. >>>> >> /net/jdsserv.ireland/scratch/month/rk99157/pstacks_ver86/click_on_connect_to_ftp_server_icon.txt >> >> >>>> >>>> 8. Browsing Samba network - ok >>>> 9. Browsing local files, clicking on files so that their default >>>> application e.g. realplayer, staroffice etc launches ok >>>> >>>> >>>> Can you please provide us with sparc and x86 packages (for test). >>>> >>>> Thanks >>>> Bob >>>> >>>> >>>> >>>> >>>> Ghee Teo wrote: >>>>> Hi Artem, >>>>> >>>>> Thanks for fixing this so rapidly! >>>>> Bob can test it out and he can verify whether the fix is good >> for >>>>> integration into HAL or he might discover other problem. >>>>> >>>>> If we get a GO from Bob, can you generate a sparc version also. >> As >>>>> this fix is only going to be available on snv 87, people who >> install >>>>> vermillion devel build will need a temporary packages for a few builds. >>>>> >>>>> Thanks, >>>>> >>>>> -Ghee >>>>> >>>>> >>>>> Artem Kachitchkine wrote: >>>>>>> You can find it at /net/mhw.prc/builds/vermillion/devel/86/. >>>>>> I reproduced the bug by installing vermillion 86 on top of >> snv_85. >>>>>> Then implemented the missing libhal functions, replaced >>>>>> /usr/lib/libhal.so.1.0.0 and the desktop seems to work okay now. >>>>>> Except for one thing: although gnome-mount and gnome-umount >> (spawned >>>>>> by gnome-volume-manager) do their job of mounting and unmounting >>>>>> volumes, they crash at the last moment with: >>>>>> >>>>>> Bonobo-CRITICAL **: file bonobo-object.c: line 327: assertion >>>>>> 'BONOBO_IS_OBJECT (object)' failed >>>>>> >>>>>> waking up the crack-smoking Bug Buddy. Tried running same >> commands >>>>>> manually from an out-of-session shell, like: >>>>>> >>>>>> gnome-umount --display=:0.0 --hal-udi=`hal-find-by-capability >>>>>> --capability=volume` >>>>>> >>>>>> and everything is peachy, no bonobo assertions. That's for y'all >> to >>>>>> investigate. >>>>>> >>>>>> If anyone wants to verify the fix, copy this over existing libhal >>>>>> and reboot: >>>>>> >>>>>> >> /net/aja.sfbay/export0/tamarack/nv-hal-ps/proto/root_i386/usr/lib/libhal.so.1.0.0 >> >> >>>>>> >>>>>> Let me know if that works for you in the short term, and if you >> want >>>>>> me to integrate it into Nevada. I can run a quick PSARC fasttrack >>>>>> and get it into snv_87. >>>>>> >>>>>> -Artem
