Re: [RFS] libzeep, again
Hi Étienne,
Op 14-11-2020 om 16:12 schreef Étienne
Mollier:
I'm not able to sponsor uploads but I took the liberty of having
a look. Please, don't forget to propagate upstream and
pristine-tar git branches. I had to reimport the orig tarball
on my end to trigger a package building. I use `salsa push`,
otherwise `git push` requires additionnal --tags or --all
options, which I always forgot when needed (Thanks Andrius for
the tip).
That's curious. Burned my fingers on that last week and so I did a
git push --all this time.
Given that the changelog mentioned closing #974074, I tried to
inject my fresh build of libzeep5 into a build of mrs, but I've
seen the same behavior as in the bug tracker on my end... :(
That's because mrs is no longer able to build with the new libzeep.
Reminds me I should still file that bugreport to drop mrs from
Debian until it is updated.
In my fresh `git clone` of libzeep, I read the following in the
debian/changelog:
+ remove override_dh_auto_configure and add --enable-shared flag to
override_dh_auto_configure-arch
and see the following in debian/rules, so not an -arch override:
override_dh_auto_configure:
dh_auto_configure -- --enable-shared --enable-documentation
so, I don't know if I'm having the right copy at hand.
I believe you do, I've been working on getting the shared library to
work in a package for four days, and this line in the changelog
slipped through. I'll fix that.
Does anyone know if it is at all possible to create a package
containing multiple shared libraries of which one is linked against
another? I ended up merging the three libs into one monolithic lib.
Too bad.
On the other hand, thanks for providing an autopkgtest!
autopkgtests are cool! :)
:-)
regards, -maarten
--
Maarten L. Hekkelman
http://www.hekkelman.com/
Reply to: