CCing pkg-kde-talk which should be the right place for this.

On miércoles, 27 de julio de 2016 12:16:17 A. M. ART Sandro Knauß wrote:
> Hey,
> first of all - I spoke yesterday with Scarlett, because she started the
> packaging and I don't want to take over here work. Currently she is very
> busy but whats to take over again if the work gets less. But till than
> she's happy if we go on and get the package rolling...


> now all points I see, that need to address before we can upload the
> qtwebchannel:
> * X: libqt5webchannel-dev: duplicate-files
> usr/share/doc/libqt5webchannel-dev/
> examples/webchannel/chatclient-html/qwebchannel.js usr/share/doc/
> libqt5webchannel-dev/examples/webchannel/nodejs/qwebchannel.js
> usr/share/doc/
> libqt5webchannel-dev/examples/webchannel/qwclient/qwebchannel.js
>  -> either link all duplicates at one or we just leave it because the
> examples should be self contained?

- Examples should not be part of a -dev package.
- Linking them, as long as they are in the same package, should be ok. It's 
simply to do too.
> P: libqt5webchannel-dev: example-unusual-interpreter usr/share/doc/
> libqt5webchannel-dev/examples/webchannel/qwclient/qwclient.js #!node
> -> the interpreter is okay in the source file so who is changing this this.
> If I look at the file I see a correct interpreter:
> #!/usr/bin/env node

I don't have the least idea :(

> * I had another licensecheck and I found smaller issues (already fixed).


> * build the qtwebchannel-doc package (I would not create a -doc and
> -doc-html package and ship everything at the -doc package)

Why not? That means:

- forcing the user to install the same doc twice, one in each format.
- we can't later add the relevant dependencies to qtdoc-opensource-src

> * move examples to doc package? I think there they match better

Examples should go in an examples package. Check other Qt submodules for 
examples on how to ship examples ;)

> * I would remove the patch examples_full_path.diff, because it only touches
> examples and there the privacy breach to not hold in my eyes - What do you
> think?

I think it's a privacy breach non the less which is quite easy to fix. Extra 
points if a proper patch for doing this at build time is upstreamed.

By the way, that patch needs the necessary headers, check

> debian/control
>  - update the descriptions, these are not matching to QtWebChannel and
> copied around from other places ( I'm not a native English speaker)

Right, those need an update.

> - add the doc package
> That's all I see, that need to be done/ discussed before the package is
> ready for upload.
> @lisandro: anything to add to the list? Any Qt5 specific things?

Some thoughts about the packging:

- debian/changelog: 
  * this is pedant, but it should really only list the inital package release 
with the proper close to the ITP. This is the first time it is uploaded so you 
don't really need to describe anything else.
  * Whoever did the initial packaging didn't follow the changelog guidelines
    [cg]. Please take a look at them and be sure to follow them. Ask if in


- debian/control:
  * Maintainer should be the Qt/KDE team.
  * Scarlett, Sandro and Simon should be listed in Uploaders, they are the 
ones doing the job after all :)

- debian/copyright
  * $QT_BEGIN_LICENSE:LGPL21$ ← this is not OK, it's just a template used by 
  * Please check other submodule sto see how this is handled. Ask if in doubt.
  * Copyright lines are not machine parseable, see

- debian/.directory really?

- debian/docs: it's empty, remove it.

- debian/libqt5webchannel-dev.install
  * usr/lib/*/qt5/examples/webchannel/ /usr/share/doc/libqt5webchannel-dev/
examples ← examples should go in it's proper package.

- debian/not-installed: our Qt not-written policy is to remove the files not 
being shipped with a commad in debian/rules, using rm -fv. We keep the v to be 
sure we know which files are being removed just by looking at the build log. 
We might revisit that policy, as I think not-installed is now supported by the 
necessary tools. Can anyone update me on this?

- debian/patches: already reviewed above.

- debian/rules: 
  * qmake will not take those flags. And if it did that would be a problem, as 
hardening enables -fPIE but we require -fPIC (which already implies -fPIE, but 
you can't use both at the same time).
  * qmake QT_BUILD_PARTS+=" src" ← why that?
  * make install INSTALL_ROOT=$(CURDIR)/debian/tmp ← why not using
    dh_auto_install? check for example qtsensors.
  * Missing -v in first and last rm call.

- debian/.gitattributes is missing, use qtbase's one as an example.

#exclude <windows.h>

Lisandro Damián Nicanor Pérez Meyer

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply via email to