Re: RFS: googlizer (updated package)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-01-06 03:31, fulapol hl wrote:
> Dear mentors,
>
> I am looking for a sponsor for the new version 0.3-4
> of my package "googlizer".
>
> It builds these binary packages:
> googlizer - utility to search Google via your GNOME menu/panel
>
> The package appears to be lintian clean.
>
> The upload would fix these bugs: 554674
>
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/g/googlizer
> - Source repository: deb-src http://mentors.debian.net/debian unstable main
> contrib non-free
> - dget
> http://mentors.debian.net/debian/pool/main/g/googlizer/googlizer_0.3-4.dsc
>
> I would be glad if someone uploaded this package for me.
>
> Kind regards
> fulapol
>
> Please CC me, I'm not in the list.
>
Hey
I missed this for c2html as well, but we are in deep freeze so uploading
to unstable requires an ok from the release team.
You are welcome to target experimental instead of unstable and the
packages can be reuploaded to unstable after the freeze.
d/patches/*: Personally I prefer not using "debian-changes-<version>".
The name does not really give any hint to what it patches and they are
also generated if the clean target is not good enough; but if you prefer
that convention it is okay. That being said, you should at least update
the header in the patches to describe exactly what has been changed/why.
d/patches/debian-changes-0.3-3.1 refers to non-existent version number
in d/changelog. I assume this was supposed to be a part of the -4 patch.
d/rules: I strongly suspect you can reduce this to the "tiny debhelper"
style without any issues[1]. When you only have one binary listed in
d/control dh_auto_install uses the package directory as install
directory (instead of d/tmp). You can add d/googlizer.xpm to d/install
in this case.
If you do not feel like re-writing the rules file, then please remove
out commented commands (e.g. #dh_link).
d/control - any reason why you put the Homepage field in the binary
section and not in the source section?
The upstream application is overlinked and does not react to
LDFLAGS/CFLAGS. Unfortunately if you add -Wl,--as-needed (to reduce
overlinking) it will fail to build. It is possible to make it build with
- --as-needed and --no-add-needed at the same time[2].
In this case I /think/ (but I could be wrong) this means something
googlizer depends on needs to be patched/updated. Maybe someone else on
this list can comment on this?
It might be a good idea to patch the upstream Makefile even further to
make it react to CFLAGS and LDFLAGS. It would make it easier for us to
later introduce different default flags on an archive wide basis (see
dpkg-buildflags).
~Niels
[1]
#!/usr/bin/make -f
%:
dh $@
[2] Insert the following flags before the `pkg-config --libs ` part in
the upstream Makefile:
- -lgtk-x11-2.0 -lglib-2.0 -lgnome-2 -lgnomeui-2 -Wl,--no-add-needed
- -Wl,--as-needed
All of the libraries listed here are present in the output of pkg-config
- --libs ...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNJcAjAAoJEAVLu599gGRCNfwP/iD34LAHhgP6LyE3lAllSLJ5
cv3WA8a7L1okNG9eGxLsTR9KggAeJxg6z/xntSsWbtzyuWJPSZEviaKAwYx4cCF7
JJtbKU6QydKUFwrRzlgT/wzOu+P+25KPGotPQHNGrCnvRg+qb6Kx+nyICiJIaJNg
ipmtyIx6zsRdebD4wnlxG6JK4jI08KRV5YGSzjx8NusnLEnmOlwBQrfbAGhwOUjD
8pIM6btdq9u1IC59z/kDfTYsuoMckWWu38eVQ5bVEE7KDGgcgtP5RE/HKguWAUa1
/ZUgPHCPqgTh/KhCIBibWLhtBn06ynatEPmMsMPzTBYPTGEVsyTUOBJ5DdLfvFmk
0Y/DPQQBDRxTzM3b8qPID0kMNEqQU8MZY8s8XyOtmwI/5MtU3LUJtno68Es5gYx4
VO6d4CXXotheziLZzE7YhylxB92akeHQKWSifYHK7K/IVnTlRDpsDgtFfcae0usp
G327cPY/OQ3EFr5C0WoaYh4Vx9vonImFLP6GMpW+Zj42ZxSaDOdEYwJBm0YqR7Ka
Bv5cd1DDIeMZkwjQPsiyCjQdbetxfkZhTIU6j4spOhM/CAprUf1IZLIgryt3HqaE
DVV3dZ45TfSVvq52jHbi/lI5fWvf3u8+d6qlg8oxpZHwjSXw69J+RNjU4DPXNJJh
Tbn1mkCDRprhlkNYzZ3d
=sWz1
-----END PGP SIGNATURE-----
Reply to: