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