Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-10-13 Thread Sean Whitton 
control: tag -1 + confirmed - moreinfo
control: noowner -1

Hello,

I'm going away for the weekend, so I'm marking this as confirmed as the
only remaining issue is extremely minor (see below).

I think that commit 240db346c4abfd3d6ccb1c9db36c7880db289f6a is ready
for upload to Debian, though it would be nice if the below is fixed.

On Thu, Oct 13, 2016 at 10:25:24PM +0800, Boyuan Yang wrote:
> 2016-10-12 21:49 GMT+08:00 Sean Whitton :
> > I suggest:
> >
> > 1) override the jquery warning, with a comment pointing to README.jquery
> > (there is a special format for lintian override comments)
> 
> I am not quite sure about what the special format for lintian override comment
> is. I only found that comments in different place would have different effect
> of showing / not showing in the verbose log. Could you please check the
> grammar of my newly added `debian/qevercloud-doc.lintian-overrides' file?
> At least lintian is accepting it.

You should put the comments above the warning (currently below).  That
way, they are associated together.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-10-13 Thread Boyuan Yang 
Hello Sean,

2016-10-12 21:49 GMT+08:00 Sean Whitton :
> I suggest:
>
> 1) override the jquery warning, with a comment pointing to README.jquery
> (there is a special format for lintian override comments)

I am not quite sure about what the special format for lintian override comment
is. I only found that comments in different place would have different effect
of showing / not showing in the verbose log. Could you please check the
grammar of my newly added `debian/qevercloud-doc.lintian-overrides' file?
At least lintian is accepting it.

> 2) ensure that dh_doxygen is run after you build the documentation.  It
> does various things like symlink template files.

Added. Looks like things are going well in build log.


The refreshed package has been uploaded to debomatic-amd64 / GitHub /
debian-mentors.


Sincerely,
Boyuan Yang

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-10-12 Thread Sean Whitton 
Hello Boyuan,

On Wed, Oct 12, 2016 at 11:03:43AM +0800, Boyuan Yang wrote:
> 2016-10-12 10:43 GMT+08:00 Sean Whitton :
> > Have you read /usr/share/doc/doxygen/README.jquery?
> >
> > I think you shouldn't be symlinking jquery.
> 
> Wow, I did not read it before since I trusted lintian :p

That's usually reasonable!

> Looks like it is kind of disagreement between the packager / uploader
> of doxygen and debian policy.

Debian Policy often lags behind best practices.  It's not necessarily a
disagreement, just that the process to update policy hasn't concluded.

> I found bug #736360 and dh_doxygen really interesting, but still kind
> of confused. dh_doxygen did not mention this embedding problem in its
> manpage, and those Debian bug reports did not give a final solution
> either. So what should I do? Just override the lintian warning?

Sorry, dh_doxygen is different from the jquery issue.

I suggest:

1) override the jquery warning, with a comment pointing to README.jquery
(there is a special format for lintian override comments)

2) ensure that dh_doxygen is run after you build the documentation.  It
does various things like symlink template files.

--
Sean Whitton


signature.asc
Description: PGP signature

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-10-11 Thread Boyuan Yang 
Hello Sean,

2016-10-12 10:43 GMT+08:00 Sean Whitton :
> Hello Boyuan,
>
> Have you read /usr/share/doc/doxygen/README.jquery?
>
> I think you shouldn't be symlinking jquery.

Wow, I did not read it before since I trusted lintian :p

Looks like it is kind of disagreement between the packager / uploader of
doxygen and debian policy.

I found bug #736360 and dh_doxygen really interesting, but still kind of
confused. dh_doxygen did not mention this embedding problem in its
manpage, and those Debian bug reports did not give a final solution
either. So what should I do? Just override the lintian warning?


Sincerely,
Boyuan Yang

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-10-11 Thread Sean Whitton 
Hello Boyuan,

On Tue, Oct 11, 2016 at 07:43:18PM -0700, Sean Whitton wrote:
> Have you read /usr/share/doc/doxygen/README.jquery?
> 
> I think you shouldn't be symlinking jquery.

It would probably be good to use dh_oxygen, too.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-10-11 Thread Sean Whitton 
Hello Boyuan,

Have you read /usr/share/doc/doxygen/README.jquery?

I think you shouldn't be symlinking jquery.

On Sun, Oct 09, 2016 at 07:19:43PM +0800, Boyuan Yang wrote:
> I made a small investigation on my own Debian testing. doing
> `file /usr/lib/x86_64-linux-gnu/*.so` would return some interesting results.
> While many libfoobar.so files is symlinking to final library so files,
> there are lots of other files are symlinking to another symlink, for example
> libfoobar.so.3, which makes a symlink toolchain. Examples include
> libpython3.5m, libkf5 series, libopencv, libform and so on.
> 
> Given so many examples, I think it should be acceptable. What do you think?

Agreed -- thanks for the investigation.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-10-09 Thread Boyuan Yang 
Hello Sean,

2016-10-09 8:36 GMT+08:00 Sean Whitton :
> Hello Boyuan,
>
>> Added a patch to disable the instructions about PDFs in Doxyfile.
>
> Upstream has made a new release 3.0.3 incorporating a fix o/
>
> Could you try building the docs with this new release, please?

I made a new release with 3.0.3 called 3.0.3+ds.

The new version has been uploaded without modification about .so
symlink; see the discussion below.

>
> Btw, the Forwarded: header should point at patches submitted, not bug
> reports without patches.  You should include the issue URI in the patch
> description, instead.  (Doesn't matter if you're able to drop the
> patch.)

OK. (Those patches are dropped.)

>> > One more thing -- the .so should be installed as
>> > libqt?evercloud.so.3.0.0, with a symlink from libqt?evercloud.so.3.
>> > See ch. 8 of Debian policy for an explanation of this practice.
>>
>> Patch added (0010-patch-library-soname-chain.patch).
>>
>> Issue forwarded: https://github.com/d1vanov/QEverCloud/issues/7
>
> In addition, the symlink in the -dev package conventionally points at
> libqt?evercloud.so.3.0.0, rather than at libqt?evercloud.so.3 (again,
> see ch. 8 of Policy which specifies that this should be a "symlink
> pointing to the shared library", though I suppose that could be
> interpreted to include pointing via another symlink).

That is an interesting issue. In my opinion, as long as the -dev package
always keep the same version as the library package (as required
by Debian Policy), symlinking to libfoobar.so.3 seems to have the same
function as symlinking to libfoobar.so.3.0.0.

I made a small investigation on my own Debian testing. doing
`file /usr/lib/x86_64-linux-gnu/*.so` would return some interesting results.
While many libfoobar.so files is symlinking to final library so files,
there are lots of other files are symlinking to another symlink, for example
libfoobar.so.3, which makes a symlink toolchain. Examples include
libpython3.5m, libkf5 series, libopencv, libform and so on.

Given so many examples, I think it should be acceptable. What do you think?


The updated version of qevercloud can be found on GitHub/debian-mentors/
debomatic-amd64.

Sincerely,
Boyuan Yang

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-10-08 Thread Sean Whitton 
Hello Boyuan,

On Fri, Oct 07, 2016 at 02:42:05PM +0800, Boyuan Yang wrote:
> Sorry for being late. I was having a holiday and turned to something else
> in the past few days :p

No worries -- so long as we don't miss the stretch freeze!

> > 1. You dropped --parallel from d/rules without explaining why in the commit
> > message.  Does it break the build?  Certainly not essential, but it's
> > nice to enable it since our buildds are so overworked.
> 
> --parallel is no longer needed to build in parallel since debhelper v10.
> I hope the build machines could recognize new debhelper soon.

I learned of this change shortly after I wrote to you :)  Cool.

> > Since 'complete' is an extreme adjective, it is odd to qualify it as
> > 'rather complete'.  I would s/rather //.
> 
> Sorry but I am not intended to fix (?) it. The function is not complete
> due to new releases of Evernote Cloud API recently, and such
> usages can be found all around the Internet.

Fair enough, you can keep 'rather complete' if you prefer it.  If I were
writing the description, I would have used 'almost complete' or 'mostly
complete'.

Also, 'presents' is odd.  Maybe: "QEverCloud is an almost complete
Evernote SDK for Qt."

That's just my preference though.  Not a big deal.

> > 3. I observed this:
> >
> > hephaestus ~ % objdump -p /usr/bin/nixnote2 | grep NEEDED
> >   NEEDED   libhunspell-1.4.so.0
> >   NEEDED   libcurl.so.4
> >   NEEDED   libpoppler-qt5.so.1
> >   NEEDED   libqt5qevercloud.so.3
> >   NEEDED   libQt5PrintSupport.so.5
> >   NEEDED   libQt5WebKitWidgets.so.5
> >   [...]
> >
> > Maybe the SONAME of qevercloud should be libQt5qevercloud, not
> > libqt5evercloud, to match this convention?  Since we can't change this
> > in the future, it would be good to get it right now.  Maybe this is
> > documented somewhere...
> 
> Upstream uses this name intentionally (the name is written in CMakeLists.txt).
> I guess he did not want to let his third-party library get confused with
> official Qt5 libraries.

You're right: https://github.com/d1vanov/QEverCloud/issues/9

> > Whether or not you build the PDFs, it would be good to handle this
> > error, which could be worrying to someone:
> >
> > sh: 1: epstopdf: not found
> > error: Problems running epstopdf. Check your TeX installation!
> >
> > If you don't want to install the PDFs, maybe you can instruct doxygen
> > not to try to run epstopdf, so that the error is not emitted.
> 
> I tried to build PDFs, but the dependency is just too large (a lot of
> texlive packages). What's more, I met FTBFS with current texlive.
> 
> Bug forwarded to https://github.com/d1vanov/QEverCloud/issues/8.
> 
> Added a patch to disable the instructions about PDFs in Doxyfile.

Upstream has made a new release 3.0.3 incorporating a fix o/

Could you try building the docs with this new release, please?

Btw, the Forwarded: header should point at patches submitted, not bug
reports without patches.  You should include the issue URI in the patch
description, instead.  (Doesn't matter if you're able to drop the
patch.)

> > Where you have
> >
> > dh_auto_{build,install}
> > dh_auto_{build,install} --builddirectory=$(_QEVERCLOUD_QT5_BUILDDIR)
> >
> > it's not clear why you have to call it twice.  I suggest adding a
> > comment saying what each of the two calls does.
> 
> Some more comments are added.

Great, those make it really clear.

> > I did some test builds and everything is looking good :)
> >
> > However, I did see this output:
> >
> > dpkg-shlibdeps: warning: package could avoid a useless dependency if
> > debian/libqt4qevercloud3/usr/lib/i386-linux-gnu/libqt4qevercloud.so.3
> > was not linked against libdl.so.2 (it uses none of the library's
> > symbols)
> > dpkg-shlibdeps: warning: package could avoid a useless dependency if
> > debian/libqt5qevercloud3/usr/lib/i386-linux-gnu/libqt5qevercloud.so.3
> > was not linked against libQt5Gui.so.5 (it uses none of the library's
> > symbols)
> > dpkg-shlibdeps: warning: package could avoid a useless dependency if
> > debian/libqt5qevercloud3/usr/lib/i386-linux-gnu/libqt5qevercloud.so.3
> > was not linked against libdl.so.2 (it uses none of the library's
> > symbols)
> >
> > Do you know whether those unneeded dependencies may be avoided?
> 
> Writing "export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed" in
> debian/rules to clean the unneeded links. libQt5Gui is gone now but libdl
> still exists.
> 
> Well they look harmless and I would just leave them there.

Yes, libdl is from glibc, so that's fine.  It's good to remove the
libqt5gui because that adds an actual binary package dependency.

> > One more thing -- the .so should be installed as
> > libqt?evercloud.so.3.0.0, with a symlink from libqt?evercloud.so.3.
> > See ch. 8 of Debian policy for an explanation of this practice.
> 
> Patch added (0010-patch-library-soname-chain.patch).
> 
> Issue

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-10-07 Thread Boyuan Yang 
Hello Sean,

Sorry for being late. I was having a holiday and turned to something else
in the past few days :p

2016-09-22 10:33 GMT+08:00 Sean Whitton :
> Hello Boyuan,
>
> A few new things:
>
> 1. You dropped --parallel from d/rules without explaining why in the commit
> message.  Does it break the build?  Certainly not essential, but it's
> nice to enable it since our buildds are so overworked.

--parallel is no longer needed to build in parallel since debhelper v10.
I hope the build machines could recognize new debhelper soon.

> 2. Some grammatical errors in package descriptions:
>
> s/documentations/documentation/
>
> s/on Evernote site/on the Evernote site/

done.

> Since 'complete' is an extreme adjective, it is odd to qualify it as
> 'rather complete'.  I would s/rather //.

Sorry but I am not intended to fix (?) it. The function is not complete
due to new releases of Evernote Cloud API recently, and such
usages can be found all around the Internet.

> 3. I observed this:
>
> hephaestus ~ % objdump -p /usr/bin/nixnote2 | grep NEEDED
>   NEEDED   libhunspell-1.4.so.0
>   NEEDED   libcurl.so.4
>   NEEDED   libpoppler-qt5.so.1
>   NEEDED   libqt5qevercloud.so.3
>   NEEDED   libQt5PrintSupport.so.5
>   NEEDED   libQt5WebKitWidgets.so.5
>   [...]
>
> Maybe the SONAME of qevercloud should be libQt5qevercloud, not
> libqt5evercloud, to match this convention?  Since we can't change this
> in the future, it would be good to get it right now.  Maybe this is
> documented somewhere...

Upstream uses this name intentionally (the name is written in CMakeLists.txt).
I guess he did not want to let his third-party library get confused with
official Qt5 libraries.

> Your `dch -r` is behind HEAD again, and your debian/3.0.2+ds-1 isn't on
> the HEAD of master.

OK now I'm trying to run dch -r on every commit. :)

>> I dropped the tex / pdf / postscript files in the -doc package because
>> they are not that
>> useful when html files are provided as well.
>
> Although HTML is considered the primary format for documentation in
> Debian packages, I would suggest including the PDFs and PS files anyway.
> Someone might want to print the documentation, or they might just prefer
> reading PDFs.  Since it's in a separate -doc package, we don't have to
> worry about cluttering up anyone's system.
>
> If you agree, and install the PDFs and PSs, it would also be a good idea
> to move the html docs into /usr/share/doc/qevercloud-doc/html.

That sounds good even if PDFs are not to be installed. I am putting them
inside the sub-directory html.

> Whether or not you build the PDFs, it would be good to handle this
> error, which could be worrying to someone:
>
> sh: 1: epstopdf: not found
> error: Problems running epstopdf. Check your TeX installation!
>
> If you don't want to install the PDFs, maybe you can instruct doxygen
> not to try to run epstopdf, so that the error is not emitted.

I tried to build PDFs, but the dependency is just too large (a lot of
texlive packages). What's more, I met FTBFS with current texlive.

Bug forwarded to https://github.com/d1vanov/QEverCloud/issues/8.

Added a patch to disable the instructions about PDFs in Doxyfile.

> Where you have
>
> dh_auto_{build,install}
> dh_auto_{build,install} --builddirectory=$(_QEVERCLOUD_QT5_BUILDDIR)
>
> it's not clear why you have to call it twice.  I suggest adding a
> comment saying what each of the two calls does.

Some more comments are added.

>> > 11. Upstream's README.md seems like a useful file.  Consider installing
>> > it to /usr/share/doc in both your -dev packages.  You should patch it to
>> > remove the stuff about building and installing the library, though.
>>
>> I thought dh_installdocs would install it (as stated in the man page) but it
>> didn't. Wrote it into docs file explicitly and patched now.
>
> I've reported #838538.
>
>> The Git repository on Github has been update, and the new packages are
>> uploaded to mentors and debomatic-amd64. The binary packages on debomatic
>> suggests that nixnote2 successfully recognized the libqt5qevercloud3
>> shlib version
>> requirement.
>
> I did some test builds and everything is looking good :)
>
> However, I did see this output:
>
> dpkg-shlibdeps: warning: package could avoid a useless dependency if
> debian/libqt4qevercloud3/usr/lib/i386-linux-gnu/libqt4qevercloud.so.3
> was not linked against libdl.so.2 (it uses none of the library's
> symbols)
> dpkg-shlibdeps: warning: package could avoid a useless dependency if
> debian/libqt5qevercloud3/usr/lib/i386-linux-gnu/libqt5qevercloud.so.3
> was not linked against libQt5Gui.so.5 (it uses none of the library's
> symbols)
> dpkg-shlibdeps: warning: package could avoid a useless dependency if
> debian/libqt5qevercloud3/usr/lib/i386-linux-gnu/libqt5qevercloud.so.3
> was not linked against libdl.so.2 (it uses none

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-24 Thread Sean Whitton 
Hello Boyuan,

One more thing -- the .so should be installed as
libqt?evercloud.so.3.0.0, with a symlink from libqt?evercloud.so.3.  See
ch. 8 of Debian policy for an explanation of this practice.

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-21 Thread Sean Whitton 
Hello Boyuan,

A few new things:

1. You dropped --parallel from d/rules without explaining why in the commit
message.  Does it break the build?  Certainly not essential, but it's
nice to enable it since our buildds are so overworked.

2. Some grammatical errors in package descriptions:

s/documentations/documentation/

s/on Evernote site/on the Evernote site/

Since 'complete' is an extreme adjective, it is odd to qualify it as
'rather complete'.  I would s/rather //.

3. I observed this:

hephaestus ~ % objdump -p /usr/bin/nixnote2 | grep NEEDED
  NEEDED   libhunspell-1.4.so.0
  NEEDED   libcurl.so.4
  NEEDED   libpoppler-qt5.so.1
  NEEDED   libqt5qevercloud.so.3
  NEEDED   libQt5PrintSupport.so.5
  NEEDED   libQt5WebKitWidgets.so.5
  [...]

Maybe the SONAME of qevercloud should be libQt5qevercloud, not
libqt5evercloud, to match this convention?  Since we can't change this
in the future, it would be good to get it right now.  Maybe this is
documented somewhere...

On Sun, Sep 18, 2016 at 09:02:42PM +0800, Boyuan Yang wrote:
> > 2. We need to test building something against your new shared library,
> > and we'll need to confirm that the right dependencies get generated for
> > it by dpkg-shlibdeps.  If you haven't done so already, could you update
> > your nixnote packaging to use your new qevercloud shlib, please?
> 
> The new version (2.0~beta9+dfsg-1) was pushed to GitHub, mentors
> and debomatic-amd64.
> Source package changed (ds -> dfsg) due to unclear license status (as
> discussed previously in nixnote2 RFS).

Your `dch -r` is behind HEAD again, and your debian/3.0.2+ds-1 isn't on
the HEAD of master.

> > 3. In a recent commit you renamed debian/{*.symbols =>
> > *.symbols.amd64}.  So now you are not providing any symbols files
> > for other architectures.  But for a shared library, you need to
> > provide a symbols or shlibs file for all the reasons described in
> > ch. 8 of the Debian Policy Manual.
> >
> > I assume that you did this rename because the symbols files is
> > architecture-dependent.  That probably means it's very fragile: changes
> > which don't break the ABI might change the symbols file.  This is a
> > known issue with C++ shared libs.[1]
> 
> It was indeed because of architecture-dependent symbols of C++.
> 
> >
> > You need to make the symbols file less fragile (some suggestions
> > involving sed(1) here[2]) so that it will work for all archs, or switch
> > to a shlibs file instead.  README.md suggests that upstream is aware of
> > the issue of ABI compatibility, so shlibs files might be enough.
> 
> Anyway I switched to shlibs using dh_makeshlibs. It is reasonable for
> this package to depend on upstream to keep ABI comaptibility, but I
> will also try to test symbol files on each release (even it is not included
> in the tarball, it can be stored in the git history).

Okay, sounds reasonable.

> The new qevercloud-doc added.
> 
> I dropped the tex / pdf / postscript files in the -doc package because
> they are not that
> useful when html files are provided as well.

Although HTML is considered the primary format for documentation in
Debian packages, I would suggest including the PDFs and PS files anyway.
Someone might want to print the documentation, or they might just prefer
reading PDFs.  Since it's in a separate -doc package, we don't have to
worry about cluttering up anyone's system.

If you agree, and install the PDFs and PSs, it would also be a good idea
to move the html docs into /usr/share/doc/qevercloud-doc/html.

Whether or not you build the PDFs, it would be good to handle this
error, which could be worrying to someone:

sh: 1: epstopdf: not found
error: Problems running epstopdf. Check your TeX installation!

If you don't want to install the PDFs, maybe you can instruct doxygen
not to try to run epstopdf, so that the error is not emitted.

> > 7. In your rules file you make a lot of explicit calls to dh_auto_*.
> > When you do something like this
> >
> > override_dh_auto_clean:
> > dh_auto_clean
> > rm -rf $(_QEVERCLOUD_QT5_BUILDDIR)
> >
> > it's fine, because it's clear to a reader that you are appending to an
> > automatic command.  However, when you do this:
> >
> > custom_regenerate_source_code:
> > (cd $(_QEVERCLOUD_GENERATOR_DIR); cmake .;)
> > dh_auto_build --buildsystem=makefile -- -C 
> > $(_QEVERCLOUD_GENERATOR_DIR)
> > mkdir -p QEverCloud/src/generated
> > etc.
> >
> > the dh_auto_build line is quite hard to understand -- someone would need
> > to look up the makefile buildsystem.  It would be better to replace that
> > with an explicit call to $(MAKE).  In dh_auto_build(1) it says "If it
> > doesn't work, you're encouraged to skip using dh_auto_build at all, and
> > just run the build process manually."
> 
> That is reasonable indeed. Switched to call $(MAKE).

Where you have

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-20 Thread Boyuan Yang 
Hello,

2016-09-17 22:31 GMT+08:00 Sean Whitton :
> The packaging is in great shape.  Here's a review for you.
[...]

FYI, I made a small update after last update, which is to fix the d/control file
to raise the debhelper dependency from 9 to 10.

The GitHub repository and mentors package have been updated.


--
Sincerely,
Boyuan Yang

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-18 Thread Boyuan Yang 
Hello,

2016-09-17 22:31 GMT+08:00 Sean Whitton :
> Hello Boyuan,
>
> On Wed, Sep 14, 2016 at 12:23:48PM +0800, Boyuan Yang wrote:
>> Yes, they are up-to-date now. The package on debian-mentors is also
>> updated.
>
> The packaging is in great shape.  Here's a review for you.

Thank you for your detailed review!

All the statements below are fixed/adjusted.

> Must-fixes:
> ---
>
> 1. The changelog entry won't close the ITP unless you put a # in front of
> the bug number!

That is indeed my mistake. Fixed.

> 2. We need to test building something against your new shared library,
> and we'll need to confirm that the right dependencies get generated for
> it by dpkg-shlibdeps.  If you haven't done so already, could you update
> your nixnote packaging to use your new qevercloud shlib, please?

The new version (2.0~beta9+dfsg-1) was pushed to GitHub, mentors
and debomatic-amd64.
Source package changed (ds -> dfsg) due to unclear license status (as
discussed previously in nixnote2 RFS).

> 3. In a recent commit you renamed debian/{*.symbols => *.symbols.amd64}.
> So now you are not providing any symbols files for other architectures.
> But for a shared library, you need to provide a symbols or shlibs file
> for all the reasons described in ch. 8 of the Debian Policy Manual.
>
> I assume that you did this rename because the symbols files is
> architecture-dependent.  That probably means it's very fragile: changes
> which don't break the ABI might change the symbols file.  This is a
> known issue with C++ shared libs.[1]

It was indeed because of architecture-dependent symbols of C++.

>
> You need to make the symbols file less fragile (some suggestions
> involving sed(1) here[2]) so that it will work for all archs, or switch
> to a shlibs file instead.  README.md suggests that upstream is aware of
> the issue of ABI compatibility, so shlibs files might be enough.

Anyway I switched to shlibs using dh_makeshlibs. It is reasonable for
this package to depend on upstream to keep ABI comaptibility, but I
will also try to test symbol files on each release (even it is not included
in the tarball, it can be stored in the git history).

> Suggestions:
> 
>
> 1. Please add Forwarded: headers to the patches.

Added (mostly Forwarded: not-needed).

> 2. It seems like debhelper's cmake buildsystem
> (/usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm) should handle
> what your 0001 patch does.  Are there situations where we wouldn't want
> GNUInstallDirs?  If not, please submit a bug against debhelper.

I was trying to bypass problem No.12 using this patch but failed. After that
I forgot to remove this patch (since it will not harm anything).

This patch is removed now.

> 3. README.md suggests that there is doxygen documentation available for
> generation and install.  Please consider installing this in a new
> qevercloud-doc binary package.

The new qevercloud-doc added.

I dropped the tex / pdf / postscript files in the -doc package because
they are not that
useful when html files are provided as well.

> 4. Since you added a "Section:" field to each binary package, the
> "Section: libs" at the top of the file does nothing.  Better to remove
> it.

Now I declared the Section in the source package section and removed
the duplicated Section:libs in binary packages.

> 5. Since debhelper 10 has just been released, consider using compat
> level 10.

Just switched.

> 6. Are you sure you need the debian/*.dirs files?  Have you tried
> building without them?  They are very rarely necessary these days.

Those files are leftovers from original upstream debian packaging
scripts and are (of course) not useful at all in this situation.

Now removed.

> 7. In your rules file you make a lot of explicit calls to dh_auto_*.
> When you do something like this
>
> override_dh_auto_clean:
> dh_auto_clean
> rm -rf $(_QEVERCLOUD_QT5_BUILDDIR)
>
> it's fine, because it's clear to a reader that you are appending to an
> automatic command.  However, when you do this:
>
> custom_regenerate_source_code:
> (cd $(_QEVERCLOUD_GENERATOR_DIR); cmake .;)
> dh_auto_build --buildsystem=makefile -- -C 
> $(_QEVERCLOUD_GENERATOR_DIR)
> mkdir -p QEverCloud/src/generated
> etc.
>
> the dh_auto_build line is quite hard to understand -- someone would need
> to look up the makefile buildsystem.  It would be better to replace that
> with an explicit call to $(MAKE).  In dh_auto_build(1) it says "If it
> doesn't work, you're encouraged to skip using dh_auto_build at all, and
> just run the build process manually."

That is reasonable indeed. Switched to call $(MAKE).

> 8. Perhaps rename custom_regenerate_source_code to include the name of
> what you're regenerating, e.g. custom_regenerate_from_thrift.

A meaningful name can be helpful. Fixed.

> 9. Your rules file contains some very long lines.  Consider inserting
> line breaks between long arguments.

Lines

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-17 Thread Sean Whitton 
Hello Boyuan,

On Wed, Sep 14, 2016 at 12:23:48PM +0800, Boyuan Yang wrote:
> Yes, they are up-to-date now. The package on debian-mentors is also
> updated.

The packaging is in great shape.  Here's a review for you.

Must-fixes:
---

1. The changelog entry won't close the ITP unless you put a # in front of
the bug number!

2. We need to test building something against your new shared library,
and we'll need to confirm that the right dependencies get generated for
it by dpkg-shlibdeps.  If you haven't done so already, could you update
your nixnote packaging to use your new qevercloud shlib, please?

3. In a recent commit you renamed debian/{*.symbols => *.symbols.amd64}.
So now you are not providing any symbols files for other architectures.
But for a shared library, you need to provide a symbols or shlibs file
for all the reasons described in ch. 8 of the Debian Policy Manual.

I assume that you did this rename because the symbols files is
architecture-dependent.  That probably means it's very fragile: changes
which don't break the ABI might change the symbols file.  This is a
known issue with C++ shared libs.[1]

You need to make the symbols file less fragile (some suggestions
involving sed(1) here[2]) so that it will work for all archs, or switch
to a shlibs file instead.  README.md suggests that upstream is aware of
the issue of ABI compatibility, so shlibs files might be enough.

Suggestions:


1. Please add Forwarded: headers to the patches.

2. It seems like debhelper's cmake buildsystem
(/usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm) should handle
what your 0001 patch does.  Are there situations where we wouldn't want
GNUInstallDirs?  If not, please submit a bug against debhelper.

3. README.md suggests that there is doxygen documentation available for
generation and install.  Please consider installing this in a new
qevercloud-doc binary package.

4. Since you added a "Section:" field to each binary package, the
"Section: libs" at the top of the file does nothing.  Better to remove
it.

5. Since debhelper 10 has just been released, consider using compat
level 10.

6. Are you sure you need the debian/*.dirs files?  Have you tried
building without them?  They are very rarely necessary these days.

7. In your rules file you make a lot of explicit calls to dh_auto_*.
When you do something like this

override_dh_auto_clean:
dh_auto_clean
rm -rf $(_QEVERCLOUD_QT5_BUILDDIR)

it's fine, because it's clear to a reader that you are appending to an
automatic command.  However, when you do this:

custom_regenerate_source_code:
(cd $(_QEVERCLOUD_GENERATOR_DIR); cmake .;)
dh_auto_build --buildsystem=makefile -- -C $(_QEVERCLOUD_GENERATOR_DIR)
mkdir -p QEverCloud/src/generated
etc.

the dh_auto_build line is quite hard to understand -- someone would need
to look up the makefile buildsystem.  It would be better to replace that
with an explicit call to $(MAKE).  In dh_auto_build(1) it says "If it
doesn't work, you're encouraged to skip using dh_auto_build at all, and
just run the build process manually."

8. Perhaps rename custom_regenerate_source_code to include the name of
what you're regenerating, e.g. custom_regenerate_from_thrift.

9. Your rules file contains some very long lines.  Consider inserting
line breaks between long arguments.

10. Do you need the --list-missing override?  That's useful for
debugging but possibly confusing in a source package you want to upload.

11. Upstream's README.md seems like a useful file.  Consider installing
it to /usr/share/doc in both your -dev packages.  You should patch it to
remove the stuff about building and installing the library, though.

12. Once #833789 is fixed, you can probably remove the
-DCMAKE_INSTALL_LIBDIR arguments from d/rules.  It would be nice to have
a comment in d/rules referencing that bug, and explaining that it should
be possibly to simplify things in the future, to remind yourself (or a
future package maintainer).  You also might want to subscribe to that bug.

Remember to run dch -r to refresh the changelog timestamp after making
changes.

[1] https://www.eyrie.org/~eagle/journal/2012-01/008.html
[2] https://wiki.debian.org/UsingSymbolsFiles

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-15 Thread Sean Whitton 
Hello Boyuan,

On Wed, Sep 14, 2016 at 12:23:48PM +0800, Boyuan Yang wrote:
> Yes, they are up-to-date now. The package on debian-mentors is also
> updated.

Thanks.  I'll get to this by Saturday at the latest.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-13 Thread Boyuan Yang 
Hello,

2016-09-12 21:34 GMT+08:00 Sean Whitton :
> Dear Boyuan,
>
> On Sun, Sep 11, 2016 at 08:48:15AM +0800, Boyuan Yang wrote:
>> > - status of lemon parser currently unclear
>>
>> This is fixed in the RFS of qevercloud before already. Of course we are
>> using the lemon parser from Debian. The bundled source code of lemon
>> is discarded in the source package. Sorry I didn't update the situation
>> on that Github thread, which is a little bit outdated.
>
> Great.
>
>> You suggested the separate packaging of qevercloudgenerator, but now we
>> seems to agree that since it is not useful for anything other than building
>> qevercloud,  it should not be packaged separately.
>
> Right.
>
>> Now the problem is focused on the separation of evernote-thrift files.
>>
>> I believe you suggested packaging thrift files alone, since the
>> separated package
>> can be used by other packages (most likely as a Build-Depend?), and to deal
>> with the FTBFS of qevercloud after the version bump of evernote-thrift, we 
>> can
>> include multiple copies. Did you suggest the coexistence of multiple versions
>> of evernote-thrift in the Debian repository, for example,
>> "evernote-thrift-1-25" and
>> "evernote-thrift-1-28"? Or if I misunderstood, it is just one package
>> "evernote-thrift"
>> but provides different versions of files inside one binary package (e.g.,
>> /usr/share/evernote/thrift/1.25/foobar and
>> /usr/share/evernote/thrift/1.28/foobar)?
>
> No, I was suggesting that you just embed the thrift files in your
> qevercloud source package, as you wanted to do originally.
>
> When I said "multiple versions in the archive" I meant copies in various
> source packages, but not in any binary packages.
>
>> Personally I am against the separated package of evernote-thrift, and
>> the main reason is that it is not useful; thrift files are technically
>> used by no one other than evernote people; developers are
>> encouraged/guided to use official Evernote SDK released by evernote,
>> which is already a generated project from the thrift files; no one
>> else is parsing thrift files by him/herself.
>
> Right.  They shouldn't be installed: just present in the qevernote
> source package for the purposes of regeneration.
>
> Could you confirm that your git repository is up-to-date with our
> discussion, so I can (finally!) do a review of your packaging, please?

Yes, they are up-to-date now. The package on debian-mentors is also
updated.


Sincerely,
Boyuan Yang

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-12 Thread Sean Whitton 
Dear Boyuan,

On Sun, Sep 11, 2016 at 08:48:15AM +0800, Boyuan Yang wrote:
> > - status of lemon parser currently unclear
> 
> This is fixed in the RFS of qevercloud before already. Of course we are
> using the lemon parser from Debian. The bundled source code of lemon
> is discarded in the source package. Sorry I didn't update the situation
> on that Github thread, which is a little bit outdated.

Great.

> You suggested the separate packaging of qevercloudgenerator, but now we
> seems to agree that since it is not useful for anything other than building
> qevercloud,  it should not be packaged separately.

Right.

> Now the problem is focused on the separation of evernote-thrift files.
> 
> I believe you suggested packaging thrift files alone, since the
> separated package
> can be used by other packages (most likely as a Build-Depend?), and to deal
> with the FTBFS of qevercloud after the version bump of evernote-thrift, we can
> include multiple copies. Did you suggest the coexistence of multiple versions
> of evernote-thrift in the Debian repository, for example,
> "evernote-thrift-1-25" and
> "evernote-thrift-1-28"? Or if I misunderstood, it is just one package
> "evernote-thrift"
> but provides different versions of files inside one binary package (e.g.,
> /usr/share/evernote/thrift/1.25/foobar and
> /usr/share/evernote/thrift/1.28/foobar)?

No, I was suggesting that you just embed the thrift files in your
qevercloud source package, as you wanted to do originally.

When I said "multiple versions in the archive" I meant copies in various
source packages, but not in any binary packages.

> Personally I am against the separated package of evernote-thrift, and
> the main reason is that it is not useful; thrift files are technically
> used by no one other than evernote people; developers are
> encouraged/guided to use official Evernote SDK released by evernote,
> which is already a generated project from the thrift files; no one
> else is parsing thrift files by him/herself.

Right.  They shouldn't be installed: just present in the qevernote
source package for the purposes of regeneration.

Could you confirm that your git repository is up-to-date with our
discussion, so I can (finally!) do a review of your packaging, please?

-- 
Sean Whitton

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-10 Thread Boyuan Yang 
Hi Sean,

2016-09-11 5:46 GMT+08:00 Sean Whitton :
> In that GitHub thread, there is mention of a parsing tool called
> 'lemon'.  Dmitry suggests packaging that separately, but you say it's
> not necessary.  Could you explain why?  Where can I find out about that
> tool?
>

"apt install lemon" will find the tool. It is part of sqlite3.

> - status of lemon parser currently unclear

This is fixed in the RFS of qevercloud before already. Of course we are
using the lemon parser from Debian. The bundled source code of lemon
is discarded in the source package. Sorry I didn't update the situation
on that Github thread, which is a little bit outdated.

> If an Evernote API change would cause qevercloud to become useless, it
> would make sense to package the Thrift IDL files separately.  When those
> were updated, qevercloud would FTBFS, and that would be a good thing
> because it would alert us that the package was broken.
>
> However, as you say, it turns out that the Evernote API is backwards
> compatible.  Even if qevercloud lagged behind other Debian packages
> using the Thrift IDL, we would want to keep qevercloud in Debian
> alongside those other packages, becauae QEverCloud would remain useful.
> So, in conclusion, it's okay to have multiple copies of the Thrift IDL
> files in the archive.

I would like to return to the very beginning of the problem:

QEverCloud upstream source code contains some generated cpp codes but
did not provide the direct way to regenerate them *within the source code*.
(Dmitry keeps the custom generator together with instructions of regeneration
inside another public Git repository, and the thrift IDL files needed
for regeneration
is in another public Git repository kept by Evernote.)

Since Debian Policy (or at least ftp-master) requires at least the
possibility to
regenerate all generated files (I believe they were thinking about
files generated
by autoconf/automake), so I repacked qevercloud and included qevercloudgenerator
and evernote-thrift files inside qevercloud source repository. So far everthing
is fine, but this is the point opinions diverge.

You suggested the separate packaging of qevercloudgenerator, but now we
seems to agree that since it is not useful for anything other than building
qevercloud,  it should not be packaged separately.

Now the problem is focused on the separation of evernote-thrift files.

I believe you suggested packaging thrift files alone, since the
separated package
can be used by other packages (most likely as a Build-Depend?), and to deal
with the FTBFS of qevercloud after the version bump of evernote-thrift, we can
include multiple copies. Did you suggest the coexistence of multiple versions
of evernote-thrift in the Debian repository, for example,
"evernote-thrift-1-25" and
"evernote-thrift-1-28"? Or if I misunderstood, it is just one package
"evernote-thrift"
but provides different versions of files inside one binary package (e.g.,
/usr/share/evernote/thrift/1.25/foobar and
/usr/share/evernote/thrift/1.28/foobar)?

Personally I am against the separated package of evernote-thrift, and
the main reason
is that it is not useful; thrift files are technically used by no one
other than evernote people;
developers are encouraged/guided to use official Evernote SDK released
by evernote,
which is already a generated project from the thrift files; no one
else is parsing
thrift files by him/herself.

There was a reason of FTBFS, but the coexistence of different versions can solve
this problem.

But don't forget that we only wanted to deal with the policy violation.

I may package evernote-thrift files if you insist, but please tell me
your preference
on the coexistence of multiple version (as stated above).

> Are you sure?  There has never been ebib version 4.5.2.  The version I
> meant was 2.6.3-1 in unstable.  Try `debcheckout ebib`.

OK I got the correct version now (2.5.4 though, I am using testing).
It is really weird, what was I looking at before? :-|

>  * * *
>
> To summarise our discussion so far:
>
> - qevercloudgenerator should not be packaged separately because it is
>   not useful for anything other than building qevercloud.

Sure.

>
> - the source package containing qevercloudgenerator should embed a copy
>   of the latest Thrift IDL that it is compatible with
>

Yes. Personally I think the embedded copy has no special functions but to
make sure the regeneration really works and makes ftp-master people and
those who examines this package against Debian Policy happy.

> - ideally qevercloudgenerator will be run during the qevercloud package
>   build, though a promise that it can be run is sufficient for the
>   ftpmasters

Yes, and in current building instruction we are choosing to run the
regeneration.


After all this is a really interesting problem, a combination of
automake/autoconf
generated files and the versioning/packaging problem of shared libraries. I have
heard that in the (unreleased) debhelper

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-10 Thread Sean Whitton 
Dear Boyuan, Dmitry,

On Thu, Sep 08, 2016 at 12:52:29PM +0300, Dmitry Ivanov wrote:
> I am the upstream developer of QEverCloud library. Sorry for the
> interference, I'd just like to clarify a bit what QEverCloudGenerator
> is and how it is intended to work.

Please don't apologise -- there's a reason Debian has these discussions
in public.  Thank you for your very valuable input.  (I won't CC you
after this message, so if you want to follow subsequent discussion
please subscribe to the Debian bug report.)

On Thu, Sep 08, 2016 at 06:36:48AM +0800, Boyuan Yang wrote:
> He just told me it is not possible, since the generator needs to be
> updated. Update in Evernote thrift files will simply leads to FTBFS
> without the update in the generator.
> [...]
> Take a look at Evernote official SDK) and the backward compatibility
> of the API. Not updating API will not cause problems,

^^ This is the most important part of your message.

If an Evernote API change would cause qevercloud to become useless, it
would make sense to package the Thrift IDL files separately.  When those
were updated, qevercloud would FTBFS, and that would be a good thing
because it would alert us that the package was broken.

However, as you say, it turns out that the Evernote API is backwards
compatible.  Even if qevercloud lagged behind other Debian packages
using the Thrift IDL, we would want to keep qevercloud in Debian
alongside those other packages, becauae QEverCloud would remain useful.
So, in conclusion, it's okay to have multiple copies of the Thrift IDL
files in the archive.

> > I had some discussions to the current maintainer of QEverCloud about
> > the possibility of updating thrift IDL files and regenerate again.
> > https://github.com/d1vanov/QEverCloud/issues/5

In that GitHub thread, there is mention of a parsing tool called
'lemon'.  Dmitry suggests packaging that separately, but you say it's
not necessary.  Could you explain why?  Where can I find out about that
tool?

Please don't be afraid of increasing the number of packages in Debian.
One of Debian's strengths, compared to other distributions, is binary
package granularity.  This is good for both package maintainers and
users, for all sorts of reasons.

> Are we talking about the same package? :p
> 
> I ran `apt-get source ebib' and got ebib v4.5.2. The debian/rules is
> nothing more
> than one line of `dh $@ --parallel --with elpa'.

Are you sure?  There has never been ebib version 4.5.2.  The version I
meant was 2.6.3-1 in unstable.  Try `debcheckout ebib`.

 * * *

To summarise our discussion so far:

- qevercloudgenerator should not be packaged separately because it is
  not useful for anything other than building qevercloud.

- the source package containing qevercloudgenerator should embed a copy
  of the latest Thrift IDL that it is compatible with

- ideally qevercloudgenerator will be run during the qevercloud package
  build, though a promise that it can be run is sufficient for the
  ftpmasters

- status of lemon parser currently unclear

Please let me know if I've misunderstood anything in writing this
summary, and thanks again for the work you've both done.

--
Sean Whitton


signature.asc
Description: PGP signature

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-08 Thread Dmitry Ivanov 
Hello,

I am the upstream developer of QEverCloud library. Sorry for the
interference, I'd just like to clarify a bit what QEverCloudGenerator is
and how it is intended to work.

Let me start from a brief description of how Thrift IDL - interface
definition language - works. It is a pseudo-programming-language
"optimized" for the definition of interfaces for structures and functions.
There's a tool called thrift compiler which can generate the source code in
various actually existing programming languages from the definition in the
form of Thrift IDL files. The entire thrift project is currently maintained
by the Apache Software Foundation - https://thrift.apache.org.

Apache's thrift compiler can produce the C++ source code from Thrift IDL
files. However, the resulting C++ code is quite inconvenient to use along
with Qt framework due to having to use non-Qt data types along with Qt data
types - it results in having to do numerous conversions between these data
types which adds to runtime overhead and overall complexity.

QEverCloudGenerator is an ad-hoc tool meant to replace the thrift compiler
for the particular case of Evernote Thrift IDL files, to generate more
Qt-friendly C++ code i.e. the code using Qt data types where
possible/feasible. The key word is "ad-hoc". It was not developed to become
another backend of the official thrift compiler which is a much more
complex task than solving a particular use case of generating some code
from a few particular Thrift IDL files using only a subset of allowed
Thrift IDL constructs. As such, QEverCloudGenerator can't be considered a
general purpose Thrift compiler generating the Qt-friendly C++ code.

Evernote people have recently released the Thrift IDL files for the new
version of their API - https://github.com/evernote/evernote-thrift/pull/6.
Currently QEverCloudGenerator cannot handle the updated Thrift IDL files as
the subset of allowed Thrift IDL constructs has been extended compared to
the previous version of API. I am in the process of making it able to
handle these new files. And unless QEverCloudGenerator becomes the general
purpose thrift compiler backend some day, the necessity for the similar
procedures should generally be expected to for future Evernote API releases.

Regards,
Dmitry Ivanov.


On Thu, 8 Sep 2016 06:36:48 +0800 Boyuan Yang <073p...@gmail.com> wrote:
> 2016-09-08 0:52 GMT+08:00 Sean Whitton :
> > The issue is that then we then have multiple copies of the thrift files
> > in Debian: a copy in each source package that needs them, either for
> > regeneration or in debian/missing-sources/.
> >
> > Suppose there is an Evernote protocol change, or some other bug that
> > means the thrift files get updated.  If there is one copy of them in
> > Debian, we just update that, and then binNMU all the packages that use
> > it, and we're done.
>
> Unfortunately things will not be the case, at least not for Evernote
thrift
> files.
>
> I had some discussions to the current maintainer of QEverCloud about
> the possibility of updating thrift IDL files and regenerate again.
> https://github.com/d1vanov/QEverCloud/issues/5
>
> He just told me it is not possible, since the generator needs to be
> updated. Update in Evernote thrift files will simply leads to FTBFS
> without the update in the generator.
>
> > Otherwise, if there are lots of copies, we have to update each package
> > separately.  That's significantly more work, and can't be done by just
> > one person, but needs the involvement of the maintainers of all those
> > packages.
> >
> > This is especially relevant if we need to update the thrift files in a
> > Debian stable release: updates to packages in a released version of
> > Debian have to go through a careful vetting procedure, and this means we
> > only have to do that once.  That saves a lot of time (and indeed makes
> > it feasible at all).
> >
> > It's possible I've misunderstood the purpose of the thrift files, though
> > -- if there was an Evernote API change, they would have to change and
> > the corresponding language-specific generators re-run, right?
>
> In this specific case, we also need to notice the slow evolvement of
> Evernote Cloud API (>= 3 years, longer than Debian stable release cycle.
> Take a look at Evernote official SDK)
> and the backward compatibility of the API. Not updating API will not cause
> problems, and it is the author of program (i.e., nixnote2 author) who has
> the responsibility to update the level of API itself uses. Even if the
Evernote
> API is updated according to the new thrift files by packagers, the added
methods
> will not be utilized until the program author decide to switch to the
> new API, and
> the changed/removed methods may lead to FTBFS.
>
> >> Is there really any previous example in Debian, that one package
> >> *should* and *do* Build-Depend on another *binary* package that only
> >> contains some description files or source codes?
> >
> > I'm not sure

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-07 Thread Boyuan Yang 
2016-09-08 0:52 GMT+08:00 Sean Whitton :
> The issue is that then we then have multiple copies of the thrift files
> in Debian: a copy in each source package that needs them, either for
> regeneration or in debian/missing-sources/.
>
> Suppose there is an Evernote protocol change, or some other bug that
> means the thrift files get updated.  If there is one copy of them in
> Debian, we just update that, and then binNMU all the packages that use
> it, and we're done.

Unfortunately things will not be the case, at least not for Evernote thrift
files.

I had some discussions to the current maintainer of QEverCloud about
the possibility of updating thrift IDL files and regenerate again.
https://github.com/d1vanov/QEverCloud/issues/5

He just told me it is not possible, since the generator needs to be
updated. Update in Evernote thrift files will simply leads to FTBFS
without the update in the generator.

> Otherwise, if there are lots of copies, we have to update each package
> separately.  That's significantly more work, and can't be done by just
> one person, but needs the involvement of the maintainers of all those
> packages.
>
> This is especially relevant if we need to update the thrift files in a
> Debian stable release: updates to packages in a released version of
> Debian have to go through a careful vetting procedure, and this means we
> only have to do that once.  That saves a lot of time (and indeed makes
> it feasible at all).
>
> It's possible I've misunderstood the purpose of the thrift files, though
> -- if there was an Evernote API change, they would have to change and
> the corresponding language-specific generators re-run, right?

In this specific case, we also need to notice the slow evolvement of
Evernote Cloud API (>= 3 years, longer than Debian stable release cycle.
Take a look at Evernote official SDK)
and the backward compatibility of the API. Not updating API will not cause
problems, and it is the author of program (i.e., nixnote2 author) who has
the responsibility to update the level of API itself uses. Even if the Evernote
API is updated according to the new thrift files by packagers, the added methods
will not be utilized until the program author decide to switch to the
new API, and
the changed/removed methods may lead to FTBFS.

>> Is there really any previous example in Debian, that one package
>> *should* and *do* Build-Depend on another *binary* package that only
>> contains some description files or source codes?
>
> I'm not sure about a package that only contains source code alone, but I
> can give you an example of one that contains source code plus some other
> stuff: dh-elpa.  If you look in the emacsen-common folder of its source
> package, you'll find some scripts.  Those get copied into every elpa-*
> binary package (with the package name substituted in).  And dh-elpa is
> added to the elpa-* package's Built-Using field.
>
> Before dh-elpa, there was a copy of those emacsen-common scripts in
> every single Emacs lisp addon package (and in package that have not yet
> been converted, it's still there, e.g. s-el).  That meant that fixing
> bugs in those scripts or improving/reworking the Emacs Lisp addon
> packaging policy[1] means updating every single Emacs Lisp addon source
> package, and re-uploading.
>
> Thanks to dh-elpa we can update the scripts in all elpa-* packages just
> by changing dh-elpa, and rebuilding the elpa-* packages.[2]

Unfortunately Evernote thrift files are neither lisp nor shared libraries.
I understand the advantage that common files get updated separately and
a rebuild solves the rest of the problem, but this is not the current case.

>> I checked ebib and find that I know nothing about emacs lisp and its 
>> debhelper.
>> Where did it remove any file?
>
> Take a look at the two overrides in d/rules.  You shouldn't need to know
> anything about Emacs lisp to understand those.

Are we talking about the same package? :p

I ran `apt-get source ebib' and got ebib v4.5.2. The debian/rules is
nothing more
than one line of `dh $@ --parallel --with elpa'.


Sincerely,
Boyuan Yang

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-07 Thread Sean Whitton 
Dear Boyuan,

On Thu, Sep 08, 2016 at 12:14:53AM +0800, Boyuan Yang wrote:
> > Are there/could there be other libraries that use code generated from
> > the Evernote thrift files?  For example, bindings for another language
> > (python, haskell, perl)?  If so, the Evernote thrift files should be in
> > their own package, and this package can build-depend on it.
> 
> If you are talking about bindings in other languages (python / haskell
> / perl /...)
> for *Evernote Cloud API*, then yes such projects do exist. For example,
> https://github.com/evernote/evernote-sdk-python and
> https://github.com/evernote/evernote-sdk-python3 and
> https://github.com/evernote/evernote-sdk-perl and
> https://github.com/evernote/evernote-sdk-csharp and
> https://github.com/evernote/evernote-sdk-cpp .
> Note that even Evernote developers does not use thrift code directly.
> All files are
> generated with some third-party generator. The motivation is clear:
> for interpreted languages (perl/python/...), parsing thrift
> description files in runtime
> is too time consuming and impossible. And for compiled languages 
> (C/C++/C#/...),
> OK, they just don't bother with the regeneration process. It is a
> one-shot process,
> the generated c/cpp/c# source codes are still clear and readable, ready to be
> embedded into other projects or made into shared library. Packaging separately
> is useless to other people.
> 
> Thrift files should be regarded as language-independent source code; It does
> not make sense for one package to Build-Depend to another package which
> only contains some source code. Those codes should be part of its own
> source code.

The issue is that then we then have multiple copies of the thrift files
in Debian: a copy in each source package that needs them, either for
regeneration or in debian/missing-sources/.

Suppose there is an Evernote protocol change, or some other bug that
means the thrift files get updated.  If there is one copy of them in
Debian, we just update that, and then binNMU all the packages that use
it, and we're done.

Otherwise, if there are lots of copies, we have to update each package
separately.  That's significantly more work, and can't be done by just
one person, but needs the involvement of the maintainers of all those
packages.

This is especially relevant if we need to update the thrift files in a
Debian stable release: updates to packages in a released version of
Debian have to go through a careful vetting procedure, and this means we
only have to do that once.  That saves a lot of time (and indeed makes
it feasible at all).

It's possible I've misunderstood the purpose of the thrift files, though
-- if there was an Evernote API change, they would have to change and
the corresponding language-specific generators re-run, right?

> Is there really any previous example in Debian, that one package
> *should* and *do* Build-Depend on another *binary* package that only
> contains some description files or source codes?

I'm not sure about a package that only contains source code alone, but I
can give you an example of one that contains source code plus some other
stuff: dh-elpa.  If you look in the emacsen-common folder of its source
package, you'll find some scripts.  Those get copied into every elpa-*
binary package (with the package name substituted in).  And dh-elpa is
added to the elpa-* package's Built-Using field.

Before dh-elpa, there was a copy of those emacsen-common scripts in
every single Emacs lisp addon package (and in package that have not yet
been converted, it's still there, e.g. s-el).  That meant that fixing
bugs in those scripts or improving/reworking the Emacs Lisp addon
packaging policy[1] means updating every single Emacs Lisp addon source
package, and re-uploading.

Thanks to dh-elpa we can update the scripts in all elpa-* packages just
by changing dh-elpa, and rebuilding the elpa-* packages.[2]

> > That would clean things up a bit, but it wouldn't help with
> > QEverCloudGenerator -- I guess that no packages other than
> > qevercloud itself will use that, right?  If it would be easier for
> > you to maintain, you could put QEverCloudGenerator in its own
> > package and build-depend on it, but that's your choice.
> 
> That would make things even more complicated and add another barely useless
> binary package into Debian, so I am not intended to pack QEverCloudGenerator
> separately.

That's fine.

> > It looks like you are have removed the files you are going to
> > regenerate from the upstream tarball.  That's okay, but you don't
> > have to do it -- you can just delete them before you regenerate
> > them/just overwrite them.  See the ebib source package for a very
> > simple example of regenerating a file without removing it from the
> > upstream tarball.
> 
> I checked ebib and find that I know nothing about emacs lisp and its 
> debhelper.
> Where did it remove any file?

Take a look at the two overrides in d/rules.  You shouldn't need to know
anything

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-07 Thread Boyuan Yang 
Hello,

2016-09-07 23:15 GMT+08:00 Sean Whitton :
> control: owner -1 !
> control: tag -1 +moreinfo
>
> Dear Boyuan,
>
> Thanks for this!  Before I do a proper review let's talk about the
> source code/repacking situation.
>
> Are there/could there be other libraries that use code generated from
> the Evernote thrift files?  For example, bindings for another language
> (python, haskell, perl)?  If so, the Evernote thrift files should be in
> their own package, and this package can build-depend on it.

If you are talking about bindings in other languages (python / haskell
/ perl /...)
for *Evernote Cloud API*, then yes such projects do exist. For example,
https://github.com/evernote/evernote-sdk-python and
https://github.com/evernote/evernote-sdk-python3 and
https://github.com/evernote/evernote-sdk-perl and
https://github.com/evernote/evernote-sdk-csharp and
https://github.com/evernote/evernote-sdk-cpp .
Note that even Evernote developers does not use thrift code directly.
All files are
generated with some third-party generator. The motivation is clear:
for interpreted languages (perl/python/...), parsing thrift
description files in runtime
is too time consuming and impossible. And for compiled languages (C/C++/C#/...),
OK, they just don't bother with the regeneration process. It is a
one-shot process,
the generated c/cpp/c# source codes are still clear and readable, ready to be
embedded into other projects or made into shared library. Packaging separately
is useless to other people.

Thrift files should be regarded as language-independent source code; It does
not make sense for one package to Build-Depend to another package which
only contains some source code. Those codes should be part of its own
source code.

Is there really any previous example in Debian, that one package *should* and
*do* Build-Depend on another *binary* package that only contains some
description files or source codes?

> That would clean things up a bit, but it wouldn't help with
> QEverCloudGenerator -- I guess that no packages other than qevercloud
> itself will use that, right?  If it would be easier for you to maintain,
> you could put QEverCloudGenerator in its own package and build-depend on
> it, but that's your choice.

That would make things even more complicated and add another barely useless
binary package into Debian, so I am not intended to pack QEverCloudGenerator
separately.

> It looks like you are have removed the files you are going to regenerate
> from the upstream tarball.  That's okay, but you don't have to do it --
> you can just delete them before you regenerate them/just overwrite
> them.  See the ebib source package for a very simple example of
> regenerating a file without removing it from the upstream tarball.

I checked ebib and find that I know nothing about emacs lisp and its debhelper.
Where did it remove any file?

What I do know is that I can override dh_clean and delete some files
sooner or later.
Overwriting seems reasonable, too.

> Let me know what you think of these suggestions.

Basically I just don't want to generate more binary packages. The current source
structure is acceptable to me, and the only problem is to decide the proper way
to regenerate source code and build the library. I may choose either to hack the
debian/rules file or to patch cmake instructions. The current implementation is
to hack debian/rules.

Sincerely,
Boyuan Yang

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-07 Thread Sean Whitton 
control: owner -1 !
control: tag -1 +moreinfo

Dear Boyuan,

Thanks for this!  Before I do a proper review let's talk about the
source code/repacking situation.

Are there/could there be other libraries that use code generated from
the Evernote thrift files?  For example, bindings for another language
(python, haskell, perl)?  If so, the Evernote thrift files should be in
their own package, and this package can build-depend on it.

That would clean things up a bit, but it wouldn't help with
QEverCloudGenerator -- I guess that no packages other than qevercloud
itself will use that, right?  If it would be easier for you to maintain,
you could put QEverCloudGenerator in its own package and build-depend on
it, but that's your choice.

It looks like you are have removed the files you are going to regenerate
from the upstream tarball.  That's okay, but you don't have to do it --
you can just delete them before you regenerate them/just overwrite
them.  See the ebib source package for a very simple example of
regenerating a file without removing it from the upstream tarball.

Let me know what you think of these suggestions.

-- 
Sean Whitton

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

2016-09-06 Thread Boyuan Yang 
Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "qevercloud"

 * Package name: qevercloud
   Version : 3.0.2+ds-1
   Upstream Author : Dmitry Ivanov 
 * URL : https://github.com/d1vanov/QEverCloud
 * License : MIT
   Section : libs

  It builds those binary packages:

libqt4qevercloud3 - Unofficial Evernote Cloud API library for Qt4
libqt5qevercloud3 - Unofficial Evernote Cloud API library for Qt5
qt4qevercloud-dev - Development files for libqt4qevercloud
qt5qevercloud-dev - Development files for libqt5qevercloud

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/qevercloud


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/q/qevercloud/qevercloud_3.0.2+ds-1.dsc

  Alternatively, one can browse the packaging scripts on GitHub:

https://github.com/hosiet/QEverCloud

  Alternatively, one can download pre-built deb packages or download
the source package on deb-o-matic:


http://debomatic-amd64.debian.net/distribution#unstable/qevercloud/3.0.2+ds-1/

This is a new package and will work as the dependency of nixnote2
(RFS: #832704) to replace nixnote2's bundled qevercloud library source
files.

Previous discussions can be found in the nixnote2 RFS, start from Message #70:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832704#70

In order to regenerate some generated cpp source/headers files, the
source code of an extra generator
(https://github.com/d1vanov/QEverCloudGenerator) and the upstream
Thrift IDL files release by Evernote Corporation
(https://github.com/evernote/evernote-thrift) was included, which made
the build system (as written in debian/rules, plus patch in
debian/patches) somehow ugly and hacky.

I am wondering if such instructions are acceptable. Reviews and
suggestions are welcomed.

  Regards,
   Boyuan Yang