On Wed, Jul 16, 2014 at 10:11 AM, Stefan Weil <s...@weilnetz.de> wrote: > Am 16.07.2014 18:49, schrieb Paolo Bonzini: >> Il 16/07/2014 18:28, Stefan Weil ha scritto: >>> Debian testing includes a brand new libiscsi, but it >>> does not include libiscsi.pc, so pkg-config won't know that it is >>> available and configure will disable libiscsi. >> >> That's a packaging bug. > > CC'ing Michael as he is the Debian maintainer of this package and > Aurélien who maintains QEMU for Debian. > > Michael, should I send a Debian bug report for libiscsi-dev? Would an > update of libiscsi for Debian stable be reasonable if versions older > than 1.9 are too buggy to be used?
If you ask debian to upgrade. Could you ask them to wait and upgrade after I have release the next version, hopefully if all goes well, at the end of this week? It contains new functionality, thanks to plieven, to better handle cases where active/passive storage arrays perform failover. > I must admit that I'm a little bit > surprised because iSCSI support worked for me quite well the last time I > used it with Debian wheezy. I think, and plieven please correct me if I am wrong, earlier version would work reasonably well for basic use but there were bugs and gaps in functionality that made it ill suited for enterprise environments. > > Regards > Stefan > >> >>> I have a patch which >>> fixes this, so QEMU for Debian testing could include libiscsi again. >>> >>> Is a feature regression like this one acceptable? Do we need additional >>> testing (maybe run the build bots with --enable-xxx, so builds fail when >>> xxx no longer works)? >> >> As mentioned in the e49ab19fcaa617ad6cdfe1ac401327326b6a2552 commit >> message, this was intentional. I was reluctant to do it, but ultimately >> Peter Lieven convinced me that it isn't just about using fancy new APIs; >> libiscsi was too buggy to be useful until release 1.8.0 (even 1.9.0 >> requires a patch to avoid segfaults, and many more if you want to run it >> on ARM). >> >> Paolo > >
