Bug#840652: any status on this?
On Sunday 04 December 2016 01:30:27 Sandro Knauß wrote:
> messagelib[debian/sid] 16da74f8b884e02a2835c6c1c92f8c2041aa27a1
> kdepim[debian/sid] fe28dd2cc76a4c13b5f214fb8d024a529bf2bb9c
> kleopatra[debian/sid] f5bf98dabe305aa781eb43abcc0c345bd265a38d
These looks trivial and the kind of issues that would either work or fail to
build.
> sune/maxy: please review
>
> the tricky part is libkleo. Because parts of libkleo the moved into QGpgME,
> and we have changes of boost::shared_ptr -> std::shared_ptr and other such
> kind of changes.
You need to give libkleo a full get rid of boost shared_ptr to get things to
work. It should just be an advanced search/replace job. And this is abi-
changing.
I saw this:
+template<typename T> std::shared_ptr<T> make_shared_ptr(boost::shared_ptr<T>&
ptr)
+{
+ return std::shared_ptr<T>(ptr.get(), [ptr](T*) mutable
{ptr.reset();});
+}
and I got quite worried. I at least need to read up a bit on how exactly a
reference is captured into a lambda to say if it is quite good, or incredibly
dangerous. Is it captured by reference or by copy ? The latter is good. the
first is quite bad.
> /<<PKGBUILDDIR>>/messagecomposer/src/composer/keyresolver.cpp: In function
> 'bool ByKeyID(const GpgME::Key&, const GpgME::Key&)':
There are apparantly two of these ...
> At least one questino from my side, if we update all fist dependencies to
> not use gpgmepp, we would also need to recompile the second level of
> dependencies (f.ex. libkleo->messagelib->kdepim). This is normally handled
> by a transition, but now we have transitions freeze... So how we get rid of
> kf5gpgmepp for stretch smoothly( after we found a way to handle libkleo)?
Doing a transition is the way to do it smoothly.
/Sune
--
I didn’t stop pretending when I became an adult, it’s just that when I was a
kid I was pretending that I fit into the rules and structures of this world.
And now that I’m an adult, I pretend that those rules and structures exist.
- zefrank
Reply to: