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

[Gianfranco Costamagna <costamagnagianfranco@yahoo.it>]

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)