Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Tim Dengel]

Hi again,

I just now noticed that the QA information on the mentors site of my
package[0] says that I have no debhelper compatibility level set and
that I don't have a watch file, but both are there in the package I
uploaded. I have no idea what went wrong.
Also, strangely, when I downloaded the package with dget to check if the
files are there, dscverify failed with a GPG error message saying it
couldn't check the signature because the public key "could not be
found", but when I do 'gpg --list-public-keys' it is there. I also
successfully verified the signature with 'gpg --verify
gnome-twitch_0.1.0-2.dsc'.

Output of LANG=C dscverify gnome-twitch_0.1.0-2.dsc :

gnome-twitch_0.1.0-2.dsc:
dscverify: gnome-twitch_0.1.0-2.dsc failed signature check:
gpg: Signature made Sat Nov 28 22:21:30 2015 CET using RSA key ID B39C07E9
gpg: Can't check signature: public key not found
Validation FAILED!!



Output of LANG=C gpg --verify gnome-twitch_0.1.0-2.dsc :

gpg: Signature made Sat Nov 28 22:21:30 2015 CET using RSA key ID B39C07E9
gpg: Good signature from "Tim Dengel "


[0] https://mentors.debian.net/package/gnome-twitch

--
Tim

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Tim Dengel]

Hi again,

I just now noticed that the QA information on the mentors site of my
package[0] says that I have no debhelper compatibility level set and
that I don't have a watch file, but both are there in the package I
uploaded. I have no idea what went wrong.
Also, strangely, when I downloaded the package with dget to check if the
files are there, dscverify failed with a GPG error message saying it
couldn't check the signature because the public key "could not be
found", but when I do 'gpg --list-public-keys' it is there. I also
successfully verified the signature with 'gpg --verify
gnome-twitch_0.1.0-2.dsc'.

Output of LANG=C dscverify gnome-twitch_0.1.0-2.dsc :

gnome-twitch_0.1.0-2.dsc:
dscverify: gnome-twitch_0.1.0-2.dsc failed signature check:
gpg: Signature made Sat Nov 28 22:21:30 2015 CET using RSA key ID B39C07E9
gpg: Can't check signature: public key not found
Validation FAILED!!



Output of LANG=C gpg --verify gnome-twitch_0.1.0-2.dsc :

gpg: Signature made Sat Nov 28 22:21:30 2015 CET using RSA key ID B39C07E9
gpg: Good signature from "Tim Dengel "


[0] https://mentors.debian.net/package/gnome-twitch

--
Tim

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Tim Dengel]

Am 03.11.2015 um 17:35 schrieb Gianfranco Costamagna:
> (please ping me when you fixed those, I don't look to mentors otherwise)

Hi Gianfranco,

I have just uploaded a new version with two patches to mentors.
The git repository I use for maintaining can now also be found on
github[0] (I use git-buildpackage).
The debian branch for unstable is debian/sid.
It also contains a debian/experimental branch that tracks upstreams
development branch.

[0] https://github.com/dengelt/gnome-twitch

--
Tim

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Paul Wise]

On Sat, Oct 31, 2015 at 11:26 PM, Tim Dengel wrote:

> The second issue is, as you said, the use of git. But adding git to the
> build dependencies would not solve this, since the .git directory is not
> contained in the original tarball, so git couldn't extract the version
> from it anyways.
>
> But I think all this is a non-issue, since the script is only used to
> tell the (upstream) build system the git version so the "about" dialog
> in the application can show that version number. If the script fails
> (like it does now) the build system falls back to the hardcoded version
> (0.1.0 in this case), and those are the versions that get packaged anyways.

You might want to talk to upstream about switching from their
homegrown system to autorevision, which takes care of this quite
nicely:

https://autorevision.github.io/about/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Gianfranco Costamagna]

Hi,




>Thanks!
>I think what helped me the most (apart from reading lots of
>documentation) was looking at existing packages in the archive.
>I specifically looked at packages using the SCons build system, since
>that is not natively supported by debhelper (like autotools is for example).
>That way I could just observe how packagers used debhelper to build with
>SCons and transfer that method to meson.
>I do think though that the whole debhelper toolchain with all the dh_*
>commands could use some more straight forward documentation, but maybe I
>just haven't found that yet.


man dh_callname is a good starting point :)

but as you said, I prior to package something new search on 
codesearch.debian.net or somewhere else
for some similar tool already there, and start from it.


>I like that solution. It isn't any harder to maintain and at least
>offers a little bit of convenience if I ever need to split the package.


wonderful!
>I think there are two issues. The first is that, for some reason, bash
>is not used to execute the script, but some other shell, maybe dash
>(even though the shebang line points to bash).
>The == operator inside the [] brackets is a bash-ism, so it will not
>work in dash.


this is true
>The second issue is, as you said, the use of git. But adding git to the
>build dependencies would not solve this, since the .git directory is not
>contained in the original tarball, so git couldn't extract the version
>from it anyways.
>
>But I think all this is a non-issue, since the script is only used to
>tell the (upstream) build system the git version so the "about" dialog
>in the application can show that version number. If the script fails
>(like it does now) the build system falls back to the hardcoded version
>(0.1.0 in this case), and those are the versions that get packaged anyways.


also true

BTW
ls -l /bin/sh
lrwxrwxrwx 1 root root 4 mag  5 11:19 /bin/sh -> dash


>I will fix that together with the lintian informational warning
>"desktop-entry-lacks-keywords-entry", once I read about making and
>managing patches with quilt. This will be a good exercise :)
>
>Also, desktop-file-validate seems like a useful program, I wonder why
>lintian doesn't use that. Maybe I will also look into that.
>
>Thanks again for your time.


well, check-all-the-things tool does it for you :)

btw the best way I found so far for managing patches is:

edit the source code
dpkg-source --commit and it will create a patch
(one edit one patch to avoid a single patch doing everything)

or git diff > patch-name.patch
git commit, git format-patch -1 and git reset --hard to the correct commit

and then add-patch patch-name.patch

after you can apply, unapply with
quilt push/pop {-a}



cheers,

G.
(please ping me when you fixed those, I don't look to mentors otherwise)

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Tim Dengel]

Am 30.10.2015 um 10:13 schrieb Gianfranco Costamagna:
> well, I started packaging in 2013 and I didn't provide good packages on the 
> first tries.
> (actually I'm still doing packaging mistakes)
> 
> You seem to be a better packager than me, and you told you are on your first 
> packaging experience...
> this is awesome :)

Thanks!
I think what helped me the most (apart from reading lots of
documentation) was looking at existing packages in the archive.
I specifically looked at packages using the SCons build system, since
that is not natively supported by debhelper (like autotools is for example).
That way I could just observe how packagers used debhelper to build with
SCons and transfer that method to meson.
I do think though that the whole debhelper toolchain with all the dh_*
commands could use some more straight forward documentation, but maybe I
just haven't found that yet.

> 
> as said before, if you don't like the solution feel free to revert the 
> change, I'm fine
> with both solutions, as long as you are aware of pro/cons of both.

I like that solution. It isn't any harder to maintain and at least
offers a little bit of convenience if I ever need to split the package.

> now another little issue:
> ../print_git_version.sh: 3: [: unexpected operator
> 
> 
> building in a clean environment shows this error.
> basically there is no git command, so use your best solution to patch the 
> source
> or add git to build-dependencies (or just discard the issue if you think this 
> is 
> 
> a non-issue)

I think there are two issues. The first is that, for some reason, bash
is not used to execute the script, but some other shell, maybe dash
(even though the shebang line points to bash).
The == operator inside the [] brackets is a bash-ism, so it will not
work in dash.

The second issue is, as you said, the use of git. But adding git to the
build dependencies would not solve this, since the .git directory is not
contained in the original tarball, so git couldn't extract the version
from it anyways.

But I think all this is a non-issue, since the script is only used to
tell the (upstream) build system the git version so the "about" dialog
in the application can show that version number. If the script fails
(like it does now) the build system falls back to the hardcoded version
(0.1.0 in this case), and those are the versions that get packaged anyways.

> $ find -type f -iname '*.desktop' -exec desktop-file-validate {} \;
> ./data/com.gnome-twitch.app.desktop: error: value 
> "GTK;GNOME;AudioVideo;Player;Video" for string list key "Categories" in group 
> "Desktop Entry" does not have a semicolon (';') as trailing character
> 

I will fix that together with the lintian informational warning
"desktop-entry-lacks-keywords-entry", once I read about making and
managing patches with quilt. This will be a good exercise :)

Also, desktop-file-validate seems like a useful program, I wonder why
lintian doesn't use that. Maybe I will also look into that.

Thanks again for your time.

--
Tim

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Gianfranco Costamagna]

Hi Tim,


>Hmm, I'm not really sure what you mean with that, but alright.


well, I started packaging in 2013 and I didn't provide good packages on the 
first tries.
(actually I'm still doing packaging mistakes)

You seem to be a better packager than me, and you told you are on your first 
packaging experience...
this is awesome :)

>Ok, that explains why the man page said I could install directly into
>debian/package if I only build one binary package.


exactly
>That makes sense, I did that now. Turns out this doesn't add much
>overhead, since the .install file is just a one-liner using a wildcard
>(at least as long as there is just one binary package).
>The new version is now uploaded to mentors.


as said before, if you don't like the solution feel free to revert the change, 
I'm fine
with both solutions, as long as you are aware of pro/cons of both.

now another little issue:
../print_git_version.sh: 3: [: unexpected operator


building in a clean environment shows this error.
basically there is no git command, so use your best solution to patch the source
or add git to build-dependencies (or just discard the issue if you think this 
is 

a non-issue)


$ find -type f -iname '*.desktop' -exec desktop-file-validate {} \;
./data/com.gnome-twitch.app.desktop: error: value 
"GTK;GNOME;AudioVideo;Player;Video" for string list key "Categories" in group 
"Desktop Entry" does not have a semicolon (';') as trailing character


the other stuff looks good to me.

cheers,

G.

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Tim Dengel]

Am 27.10.2015 um 11:53 schrieb Gianfranco Costamagna:
> Hi,
> 
> (let me say, based on your answers I have difficulties in understanding how 
> possibly
> your first package can be so good :) )

Hmm, I'm not really sure what you mean with that, but alright.

> well, first there is a dh_auto_install step, where everything is moved to 
> debian/tmp
> (via DESTDIR), and then a dh_install where packages are split

Ok, that explains why the man page said I could install directly into
debian/package if I only build one binary package.

> Let me assume in the future you will like to split the package, that way
> I guess you might just tweak the dh_install and nothing more
> (but as soon as there is no automatic install by running "make install"
> they are both equivalent)
> 
> [...]
> 
> I guess the politically correct way is:
> install in dh_auto_install everything into debian/tmp, and add an .install 
> file
> to make sure files are moved into dh_install.
> 
> that way a future package split will be easier
> (this is how I would do it, but if you don't want to do I can live happy to)

That makes sense, I did that now. Turns out this doesn't add much
overhead, since the .install file is just a one-liner using a wildcard
(at least as long as there is just one binary package).
The new version is now uploaded to mentors.

> 
> cheers,
> 
> G.
> 

--
Tim

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Gianfranco Costamagna]

Hi,

(let me say, based on your answers I have difficulties in understanding how 
possibly
your first package can be so good :) )

>I installed into debian/package because "man dh_auto_install" told me
>that "[...]the files are installed into debian/package/ if there is only
>one binary package. In the multiple binary package case, the files are
>instead installed into debian/tmp/ [...]".
>Although there is no reason given why it should be debian/package in one
>case and debian/tmp in the other. What's the difference?


well, first there is a dh_auto_install step, where everything is moved to 
debian/tmp
(via DESTDIR), and then a dh_install where packages are split

(you mention an exception of the rule, and I agree with you on that point)

>I overrode dh_auto_install because that is where "normally" (when using
>autotools for example) the "make install" stage of the process is

>executed, right?

true

>And the "ninja install" command would be my equivalent of that "make
>install".
>After that, I thought, dh_install could be used to install files that
>were not picked up by the call to make (or ninja in my case).


true

>If that is not the case, what difference does overriding dh_install make
>in contrast to overriding dh_auto_install? Both seem to produce a
>working package for me.


actually you are completely right, but I guess is a matter of taste :)

Let me assume in the future you will like to split the package, that way
I guess you might just tweak the dh_install and nothing more
(but as soon as there is no automatic install by running "make install"
they are both equivalent)

>Also, the command you proposed would also install into
>debian/gnome-twitch, but at the top you said I should be installing into
>debian/tmp? I'm a little confused ;)


I guess the politically correct way is:
install in dh_auto_install everything into debian/tmp, and add an .install file
to make sure files are moved into dh_install.

that way a future package split will be easier
(this is how I would do it, but if you don't want to do I can live happy to)

>While writing an answer to this, I just realized that make also takes
>the -C option, I didn't know that before.

>So yes, that would probably be a good idea, I'll do that. 


let me know whenever you have something to look at :)
(the above discussion is obviously not a showstopper, because I guess it is 
just a matter of
knowing how your package will evolve)

cheers,

G.

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Tim Dengel]

Am 26.10.2015 um 19:00 schrieb Gianfranco Costamagna:
> Hi, the packaging looks good to me (note: I didn't do a full review)

Hi, thanks for looking at my package!

> however I don't like your dh_auto_install target override.
> 
> dh_auto_install should install into debian/tmp, not into debian/package.

I installed into debian/package because "man dh_auto_install" told me
that "[...]the files are installed into debian/package/ if there is only
one binary package. In the multiple binary package case, the files are
instead installed into debian/tmp/ [...]".
Although there is no reason given why it should be debian/package in one
case and debian/tmp in the other. What's the difference?

> I propose you to use dh_install like this:
> 
> override_dh_install:
> 
> DESTDIR=$(CURDIR)/debian/gnome-twitch ninja -C build install
> 
> what do you think?

I overrode dh_auto_install because that is where "normally" (when using
autotools for example) the "make install" stage of the process is
executed, right?
And the "ninja install" command would be my equivalent of that "make
install".
After that, I thought, dh_install could be used to install files that
were not picked up by the call to make (or ninja in my case).

If that is not the case, what difference does overriding dh_install make
in contrast to overriding dh_auto_install? Both seem to produce a
working package for me.

Also, the command you proposed would also install into
debian/gnome-twitch, but at the top you said I should be installing into
debian/tmp? I'm a little confused ;)

> you could also use MAKE=ninja and
> $(MAKE) during the calls, to keep it simple and possible to easily change the 
> build system.

While writing an answer to this, I just realized that make also takes
the -C option, I didn't know that before.
So yes, that would probably be a good idea, I'll do that.

--
Tim

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Gianfranco Costamagna]

Control: owner -1 !

Hi, the packaging looks good to me (note: I didn't do a full review)however I 
don't like your dh_auto_install target override.

dh_auto_install should install into debian/tmp, not into debian/package.

I propose you to use dh_install like this:

override_dh_install:

DESTDIR=$(CURDIR)/debian/gnome-twitch ninja -C build install

what do you think?

you could also use MAKE=ninja and
$(MAKE) during the calls, to keep it simple and possible to easily change the 
build system.



note: I didn't try to install and test, I'll do as soon (together with a full 
copyright review)
as soon as the above is fixed/answered


Il Sabato 24 Ottobre 2015 9:39, Tim Dengel  ha 
scritto:
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gnome-twitch"

* Package name: gnome-twitch
  Version : 0.1.0-1
  Upstream Author : Vincent Szolnoky 
* URL : https://github.com/Ippytraxx/gnome-twitch
* License : GPL-3+
  Section : video

It builds those binary packages:

  gnome-twitch - GNOME Twitch app for watching Twitch.tv streams without
a browser

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

http://mentors.debian.net/package/gnome-twitch


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

  dget -x
http://mentors.debian.net/debian/pool/main/g/gnome-twitch/gnome-twitch_0.1.0-1.dsc


Regards,
   Tim Dengel

Bug#802848: RFS: gnome-twitch/0.1.0-1 [ITP]

[Tim Dengel]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gnome-twitch"

* Package name: gnome-twitch
  Version : 0.1.0-1
  Upstream Author : Vincent Szolnoky 
* URL : https://github.com/Ippytraxx/gnome-twitch
* License : GPL-3+
  Section : video

It builds those binary packages:

  gnome-twitch - GNOME Twitch app for watching Twitch.tv streams without
a browser

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

http://mentors.debian.net/package/gnome-twitch


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

  dget -x
http://mentors.debian.net/debian/pool/main/g/gnome-twitch/gnome-twitch_0.1.0-1.dsc


Regards,
   Tim Dengel