Also sprach Arnaud Patard:
> Guillaume Rousse <[EMAIL PROTECTED]> writes:
> 
>> Since I started testing xen on mandriva one month ago, I keep
>> discovering various issues, such as:
>> - documentation not build (#27620)
> 
> This patch is already in my patch-queue. iirc the documentation was not
> "building" sometime ago. If it's working now, the doc will be readded.
> 
>> - lack of libvnc support, preventing HVM usage (#27652)
> 
>  Like Qemu, Xen can use the SDL to render the screen. That's what I'm
>  using here with to test hvm since about 1 year and windows XP is to be
>  happy with it. So, HVM works.
Did you tried it ? It only works with initial installation phase, with
minimal resolution from windows side. It fails after first windows reboot.

>  Very small detail (no irony inside): libvnc is in contrib and Xen in
>  main. So linking to it is not possible.
libvnc is in contrib because I did introduce it, and I couldn't put it
to main. However, nothing prevents you from moving it, now the hard work
is done.

>> - wrong default network configuration [#27674)
> 
> Can't reproduce it here. Either it's a bug on your setup or it's a real
> bug. With so few information, it can't be determined.
Maybe you could ask on bugzilla then ? That´s the dedicated tool for it,
after all.

The problem was also found by other users:
http://article.gmane.org/gmane.comp.emulators.xen.user/17846
Any you have also details on xen-devel ML, with patch accepted upstream:
http://lists.xensource.com/archives/html/xen-devel/2006-12/msg00764.html

>> - kernel package not creating correct initrd or source symlinks
>> (#27617)
> 
> This is working like this since we have Xen because Xen needs grub and
> lilo is installed by default. One can't ask to the script used to create
> the initrd to install grub and replace lilo behind user's back.
You're mixing issues here. Whatever bootloader you use, you have to
recreate initrd. If dedicated postinstall script can't do it without
changing bootloader, then you have to find another way of doing it. Or
correct the script to make it more flexible.

> 
>> - outdated package (not even final 3.0.3)
> 
> It's a matter of things like working only on it for about 2 weeks
> without doing something else. Xen is developped on 2.6.16 with some
> backports from newer kernels so it takes long time to do it for
> 2.6.17. I don't even talk about regressions.
This is only for kernel parts, the userland stuff should be simpler to
update I guess.

>> - etc...
> 
> what do you mean by that ? if you're talking about bugs like 'id X is
> respawning too fast', it's not a bug in Xen unless you think that
> something running inside the host can fix the guest... They're not
> closed because there was no application responsible for installing the
> Mandriva inside a guest. Now that there's drakvirt, they may be fixed
> but it's not a bug in Xen package.
It's quite difficult to find what is a bug in xen package and what is
not when we don't have even a final version labeled as stable by
upstream developers. And they are far more serious reports than this one.

>> Whereas making errors happens to everyone, I'm quite concerned that
>> despite reporting every issue with bugzilla, I had absolutly no response
>> sofar from maintainer, Arnaud... And as the package is protected by
>> SVN
> 
> hm... How should I understand that ? something like "I'm working on Xen so I
> want the maintainer to stop what he's doing now and work with me on it" ? :)
No. Just I'd like the maintainer to show he's listening, and interested
in other people feedback, which you just did, thanks.

[..]
>> Now, what can we do for improving the situation ? I'd like Arnaud to
>> manifest himself once for a while. Otherwise, maybe we could start a
>> parallel xen packaging, with another xen package in contrib, and the xen
>> patch integrated into some non-official kernel ? I hate duplicating
>> work, but I don't really see any other situation.
> 
> There is really no point in doing an other package. It has been never
> said that the issues will never be fixed. Things are taking time. That's
> all.
can you give an ETA then ?

Reply via email to