Re: RFS: spice
Hi, Michael,
On Sun, Mar 6, 2011 at 7:34 PM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> spice requires on spice-protocol >= 0.7.0, it wont built with
> spice-protocol 0.6.3 or 0.6.4. Ditto for older spice, 0.6.4
> needs spice-protocol=0.6.4, and spice 0.6.3 needs 0.6.3 protocol,
> it does not comiple if the version condition is not met.
I just think spice need the same version(at lease big version, such as 0.8)
spice-protocol to build, so I'll add spice-protocol (>= 0.8.0) to spice
build-depends.
>
> I added this versioned build-dependency locally but didn't push
> it out, you come faster.
>
> Please also ensure that spice can be re-built without cleaning,
> right now on any build error it starts with ./configure (in celt)
> again and later fails due due to EEXIST:
>
> build-stamp:
> cd celt && ./configure --prefix=/usr && cd ..
> $(MAKE) -C celt
> ln -s celt/libcelt celt051
> sed 's#\/usr#$(CURDIR)#' celt/celt051.pc |sed 's#/include##'|sed 's#/lib#/celt051/.libs#'>celt051.pc
> PKG_CONFIG_PATH=/usr/share/pkgcnfig:/usr/lib/pkgconfig:$(CURDIR) ./configure --prefix=/usr --enable-gui
> $(MAKE)
> touch build-stamp
>
> This better be split into 4 different targets depending one on
> another. Again, I did all this locally and I told you about that,
> but you prefer your to do the work twice, -- I'm fine with that.
I updated build-stamp target, and now it can be build again
without clean.
It's well to split build-stamp and clean to several part, would you
like push you changes to git ?
>
> Besides, this PKG_CONFIG thing with generation of celt051.pc and the
> symlink (where it FTBFS twice in a row) aren't needed: use
> CELT051_CFLAGS and CELT051_LDFLAGS pointing to $(CURDIR)/celt/libcelt,
> and ./configure will figure out the rest without additional ugliness.
It's really a elegance method, no need to hijack PKG_CONFIG now.
> Another thing: does libcelt051 development files it installs really
> needed? It looks like they're not used even for spice-dev package,
> but I'm not sure, I haven't looked.
Spice may not use celt051 development files any more, but
other packages may need it. IMO, even though celt051 is
embedded in spice, everything celt051 install as a standalone
package should be installed.
>
> An important note: the source contains 3 autogenerated files
> (server/generated_{,de}marshallers.{c,h}), with proper rules
> to re-generate from spice.proto when out of date. In order
> to re-generate these files, one need python-pyparsing package
> (pyparsing python module), and ofcours python interpreter
> itself. I think this should be added to build-depends, with
> appropriate comment.
In normal situation, these files should be generated by upstream
release manager before every new release, if some day we
changed spice.proto for Debian, we can regenerate
server/generated_{,de}marshallers.{c,h} and create a patch, or
add python-pyparsing to build-depends just as you said. If we
add now, package builder need install unnecessary packages
to build spice, it's boring, especially in clean room build situation.
>
> And one more thing: is it really necessary to list all copyright texts
> from almost every individual source file in debian/copyright? I don't
> know, but the resulting debian/copyright looks quite a bit messy...
>
Some files in spice is released under different license or copyright
by different object, I classify each file by license and copyright
onwer to shorten it, but, as you see, it is still long.
After DEP-5 becomes to Debian standard, debian/copyright may
be simplified.
> I did everything already locally, with just a few tweaks missing,
> and I told you yesterday I'm testing the package. You at least
> may tell the next time you will ignore anyone else's work.
>
It's my mistake, I'm very very sorry for that. such situation will not
happen any more.
I've pushed my changes to git.d.o , hope this change fine.
Before spice can enter Debian, there are still may things to do,
so if you think something don't fit your requirement, fell free to
improve it.
Thanks and Regards,
--
Liang Guo
http://bluestone.cublog.cn
Reply to: