好的，正在解决
解决，已经上传
guile有点问题，不过不大，我尽快看看gnome库里面的其他依赖问题
重新编译的guile 版本 1.6.4-14已经上传，因为1.6.7会引入magic 很多冲突的依赖，无法通过spec简单修改解决，没有打包。
evolution 已经解决并经过测试 :twisted: ，上传中
evolution 的src源 采用apt中的最新版本2.2.3-12,spec中我把关于dbus的依赖调整了一下，其他的并没有改变，所以没有将diff列出来，然后上传了新的src等rpm，版本号未改，请老大见谅
解决gnome-volume-manager不能自动挂载u盘问题，因为kanker兄hal打包过程中没有在/etc/hal/device 下创建fstab-sync.hal链接，此链接本应在hal软件包中安装。而g-v-m只能查找这个链接后才能获得fstab的信息并工作。但是由于magiclinux中hal，dbus的问题比较尖锐，所以我没有修改原hal软件包中任何文件，在原有基础的spec做了一点调整，使生成的hal-gnome中包含此链接（原来安装无此文件），并更正了hal-gnome的依赖关系，这样也可以免去升级hal的麻烦。为了与magic原由的hal等包配合，版本号仍为hal-gnome-0.48-2mgc，并单独上传hal-gnome，（src文件为原来的0.48-1,我没有找到kanker兄0.48-2的src，但是kanker兄做的更改不会影响到hal-gnome，所以就没有什么问题。因此我没有上传我新的src.rpm,上传如果有人重新编译生成的hal可能与kanker兄的0.48-2同号版本冲突）
重新编译的guile 版本 1.6.4-14已经上传，因为1.6.7会引入magic 很多冲突的依赖，无法通过spec简单修改解决，没有打包。
好，我会尽快上传。
evolution 已经解决并经过测试 :twisted: ，上传中
evolution 的src源 采用apt中的最新版本2.2.3-12,spec中我把关于dbus的依赖调整了一下，其他的并没有改变，所以没有将diff列出来，然后上传了新的src等rpm，版本号未改，请老大见谅
版本号还是要+1，这样可以让之前装了的人用 apt-get upgrade 自动升级，而 spec 我也将提交到 SVN 仓库中予以保存。顺便提一句，我们打包的所有 spec 文件和补丁都是保存在我们的SVN 仓库中的，可以通过 web 查看到：
http://svn.gnome-cn.org/repos/gnomerpms/trunk/specs/
解决gnome-volume-manager不能自动挂载u盘问题，因为kanker兄hal打包过程中没有在/etc/hal/device 下创建fstab-sync.hal链接，此链接本应在hal软件包中安装。而g-v-m只能查找这个链接后才能获得fstab的信息并工作。
这个我还是不太好理解，可否详细阐述？g-v-m 和 fstab-sync.hal 的关系是什么？FC4 系统里也没有这个文件啊。
:neutral: /etc/hal/device.d,打错了
当发现一个新的device的时候，hal会到/etc/hal/device.d里面查找.hal文件读取相关信息并且进行一系列操作。（.hal文件都是symbolic link，名字不一定与源文件相同，fstab-sync.hal也可以命名为其他的名称，但是一般hal的spec默认好象是50-fstab-sync.hal）其实也就是调用fstab-sync等命令，Fstab-sync会添加这个device信息到/etc/fstab，这样gnome-vfs就能找device的信息，gnome-volume-manger才能够找到新的device。
比如新的device是/dev/sda1
如果没有fstab-sync的链接文件fstab-sync.hal在/etc/hal/device.d
那么hal不会调动fstab-sync在/etc/fstab文件中加入/dev/sda1这样一行，那么gnome-vfs就不能在fstab找到/dev/sda1,gnome-volume-manage不能获得信息，就不能自动挂载
会出现提示
manager.c/734: New Device: /org/freedesktop/Hal/devices/block_8_0
manager.c/734: New Device: /org/freedesktop/Hal/devices/block_F4F6-DC04
manager.c/770: Changed: /dev/sda1
manager.c/712: Added: /dev/sda1
mount: can't find /dev/sda1 in /etc/fstab or /etc/mtab
如果建了链接，这个问题就会得到解决。而建链接可以手动，但是一般都是hal打包时候自动生成，比如kanker兄打的包会在/etc/hal/device.d生成60-pmount-hal.hal， 40-hal-hotplug-map.hal这两个链接，我打包的时候尽量避免与kanker兄打的包冲突，所以我把spec改了一下，把解决这个链接的任务交给了hal-gnome，这样不用重装hal
by the way, evolution的新版本已经重新上传，版本号+1 为2.2.3-13
我听 kanker 说，他正是用 pmount 取代了 fstab-sync，也就是说这是刻意而为的，pmount 可以完成 fstab-sync 的功能，只是不知道和 gnome 配不配。我觉得我们应从这里着手研究一下。
简单的搜索给出了如下的结果：
http://mail.gnome.org/archives/utopia-list/2004-December/msg00002.html
http://lists.debian.org/debian-gtk-gnome/2004/12/msg00095.html
http://patches.ximian.com/index.php/SuSE_10_With_pmount
结果显示：
1）g-v-m 可以配合 pmount 工作，gentoo, ubuntu 已经这么干了
2）为了能工作，需要特殊的配置开关来编译
3）有传说 gnome-vfs 需要打补丁，不过还不确定。
根据和 kanker 的讨论，pmount 会被坚持下来作为 ML 将来版本的标配，所以我们研究一下会很有意义的。
恩，我正在研究一下g-v-m的spec，或许有所帮助,
不太好解决，打些patch可能会解决问题，不过pacth的版本要求比较高，而且高版本对dbus，hal的高版本依赖严重，是个问题。手动修改patch也可以，不过如果gnome-vfs仍需打补丁的话，问题就更不好办了。
gnome-volume-manager-1.2.2-5上传完毕，已经解决pmount的问题，默认挂载采取pmount，请lonestar老大查收
gnome-vfs不需要打补丁
太好了，我明天就试验一下。另外，今天 nautilus 的 bug#18 也解决了，真是好消息连连啊
解决了这个，是不是 gnome/cn rpms for ML 2.0 就完全没问题了？
基本上解决了吧，我只安装了apt的gnome库里面的，以及由它们引出来的依赖关系。
其他的应该不会很重要，有的话也比较容易解决了