Bug#474615: libgtkol: contains binaries without source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, I take that back. Upstream's "make dist" misses out half the tarball, so no, it's not going to be easier to do it that way. I'll try to prepare a cleaned-up tarball with only unnecessary files missing. Simon -BEGIN PGP SIGNATURE- iD8DBQFH+SGHWSc8zVUw7HYRAkhzAKDLM0ll4Avb/pUEYGS0vvmCv+LrUQCfR3bJ c4TnZLvBsTr1As9mwyMUrPc= =R4+b -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474615: libgtkol: contains binaries without source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: libgtkol Version: 1.4.1 Severity: serious Justification: Policy 2.1, 2.2.1 libgtkol's upstream tarball contains several copies of a binary "xml-reader", md5sum d1c995b3108329099b1976592979785c, which does not appear to come with source code. This is a violation of the DFSG, and probably not legally distributable either (since the package is under the GPL). The upstream tarball also contains: - - config.guess, config.sub, COPYING and ltmain.sh as symlinks instead of plain files - - an assortment of files that should be generated at build time: config.h, config.log, config.status, libgtkol-1.4.pc, Makefile, stamp-h1 It appears that the upstream has just run "make clean" on a build tree and tarred up the result, rather than using "make dist" or (better) "make distcheck". Rather than just stripping the xml-reader binaries from the tarball, it would probably be a good idea to make the replacement tarball using "make dist" or "make distcheck", to make it easier (probably, trivial) to fix #442637 (which is the reason I was looking at this package in the first place). Regards, Simon - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- iD8DBQFH+R07WSc8zVUw7HYRAk1iAJ4u5ei6DTlbz2g+hj1pSBHufkJVEgCg5dsI o3Ur19bMRD2iJp9w1QZapmg= =G3xK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474615: libgtkol: contains binaries without source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Apr 06, 2008 at 08:16:23PM +0100, Simon McVittie wrote: >OK, I take that back. Upstream's "make dist" misses out half the >tarball, so no, it's not going to be easier to do it that way. > >I'll try to prepare a cleaned-up tarball with only unnecessary files >missing. Great that you are looking into this. No need for you to prepare a new tarball: I already (in the form of a cdbs snippet) have a mechanism for autorebuilding tarball by simply listing the files that needs to be stripped. So just resolving the exact files that needs to be stripped from the upstream tarball should be enough to work from. I can work from the files you mentioned already, or if you want to complete your work on this bug yourself I can help you use the cdbs snippet yourself. Which do you prefer? And would you perhaps be interested in helping maintain this package in the future? I would be happy to grant you write access to the VCS used for the packaging, if you are interested. Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH+Sa2n7DbMsAkQLgRAujTAKCfko9cIKk+Hwn8v7/2vk2URWHRbACdH7w/ 5uz3rIR3mcpMF5Xg7dHrpcc= =6P9F -END PGP SIGNATURE-
Bug#474615: libgtkol: contains binaries without source code
On Sun, 06 Apr 2008 at 21:38:30 +0200, Jonas Smedegaard wrote:
> On Sun, Apr 06, 2008 at 08:16:23PM +0100, Simon McVittie wrote:
> >OK, I take that back. Upstream's "make dist" misses out half the
> >tarball, so no, it's not going to be easier to do it that way.
> >
> >I'll try to prepare a cleaned-up tarball with only unnecessary files
> >missing.
>
> Great that you are looking into this.
>
> No need for you to prepare a new tarball: I already (in the form of a
> cdbs snippet) have a mechanism for autorebuilding tarball by simply
> listing the files that needs to be stripped.
I noticed. I attach a diff against collab-maint svn that sets up that
snippet to build version 1.4.1+dfsg1, which is what I'd have been asking
someone to NMU if you hadn't responded.
(I must admit that I don't much like the cdbs setup of this particular
package - the copyright-tracking stuff in particular seems incredibly fragile,
and I've been fighting with build systems for bug-squashing NMUs all weekend.
Still, it's your package...)
> And would you perhaps be interested in helping maintain this package in
> the future? I would be happy to grant you write access to the VCS used
> for the packaging, if you are interested.
I'm in collab-maint already (I have a package in bzr there), but to be honest
my only interest in libgtkol is that it had a release-goal bug that looked
easy! I didn't realise at that point that I'd be filing and fixing an RC bug
as a result...
Simon
Index: debian/control
===
--- debian/control (revision 9098)
+++ debian/control (working copy)
@@ -14,8 +14,8 @@
Provides: libgtkol-dev
Conflicts: libgtkol-dev
Architecture: any
-Description: GTK C++ Object Layer - development files
- GTK C++ Object Layer based on the libgenerics abstract services and the
+Description: GTK+ C++ Object Layer - development files
+ GTK+ C++ Object Layer based on the libgenerics abstract services and the
Gtk API.
.
Offers a complete intuitive object API without restricting access to
@@ -28,8 +28,8 @@
Depends: ${shlibs:Depends}
Suggests: libgd-docs
Architecture: any
-Description: GTK C++ Object Layer - shared libraries
- GTK C++ Object Layer based on the libgenerics abstract services and the
+Description: GTK+ C++ Object Layer - shared libraries
+ GTK+ C++ Object Layer based on the libgenerics abstract services and the
Gtk API.
.
Offers a complete intuitive object API without restricting access to
@@ -40,8 +40,8 @@
Package: libgtkol-docs
Section: doc
Architecture: all
-Description: GTK C++ Object Layer - documentation
- GTK C++ Object Layer based on the libgenerics abstract services and the
+Description: GTK+ C++ Object Layer - documentation
+ GTK+ C++ Object Layer based on the libgenerics abstract services and the
Gtk API.
.
Offers a complete intuitive object API without restricting access to
Index: debian/changelog
===
--- debian/changelog (revision 9098)
+++ debian/changelog (working copy)
@@ -1,3 +1,15 @@
+libgtkol (1.4.1+dfsg1-0.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix failure to double-build by restoring the (slightly strange) contents
+of the upstream tarball during clean (Closes: #442637).
+- Please attempt a double-build at least once per upstream release, since
+ you'll likely need to revert this if upstream start using 'make dist'
+ properly
+ * Quieten lintian by giving GTK+ its full title in debian/control
+
+ -- Simon McVittie <[EMAIL PROTECTED]> Sun, 06 Apr 2008 18:08:28 +
+
libgtkol (1.4.1-2) unstable; urgency=low
* Change debian/watch to use svn-upgrade (not uupdate invoked by default).
Index: debian/rules
===
--- debian/rules (revision 9098)
+++ debian/rules (working copy)
@@ -23,6 +23,26 @@
DEB_UPSTREAM_URL = http://prdownloads.sourceforge.net/$(pkgbasename)
DEB_UPSTREAM_TARBALL_MD5 = f8b7acc0fcd9da0a3931dc14d7d262ae
+DEB_UPSTREAM_REPACKAGE_DELIMITER = +
+DEB_UPSTREAM_REPACKAGE_TAG = dfsg1
+DEB_UPSTREAM_TARBALL_VERSION_MANGLE = s/\\+dfsg1$$//
+
+DEB_UPSTREAM_REPACKAGE_EXCLUDE = \
+xml-reader \
+source/xml-reader \
+gtkol-demo/xml-reader \
+config.log \
+config.status \
+*.pc \
+autom4te.cache \
+config.h \
+Makefile \
+*/Makefile \
+*/.deps \
+*.so \
+*.loT \
+stamp-h1
+
# Disable samples for now - it fails to build with "/usr/bin/ld: gtkol-runtime.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC"
#DEB_CONFIGURE_USER_FLAGS = --enable-examples
@@ -30,10 +50,6 @@
#DEB_INSTALL_EXAMPLES_$(pkgname)-dev = samples/*
-# Avoid binaries distributed with upstream tarball
-clean::
- rm -f xml-reader samples/gtkol-runtime/xml-reader
-
# Let d-shlibs calculate development package dependencies
# and handle shared lib
Bug#474615: libgtkol: contains binaries without source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Apr 06, 2008 at 10:15:37PM +0100, Simon McVittie wrote: >On Sun, 06 Apr 2008 at 21:38:30 +0200, Jonas Smedegaard wrote: >> On Sun, Apr 06, 2008 at 08:16:23PM +0100, Simon McVittie wrote: >> >OK, I take that back. Upstream's "make dist" misses out half the >> >tarball, so no, it's not going to be easier to do it that way. >> > >> >I'll try to prepare a cleaned-up tarball with only unnecessary files >> >missing. >> >> Great that you are looking into this. >> >> No need for you to prepare a new tarball: I already (in the form of a >> cdbs snippet) have a mechanism for autorebuilding tarball by simply >> listing the files that needs to be stripped. > >I noticed. I attach a diff against collab-maint svn that sets up that >snippet to build version 1.4.1+dfsg1, which is what I'd have been >asking someone to NMU if you hadn't responded. Excellent! >(I must admit that I don't much like the cdbs setup of this particular >package - the copyright-tracking stuff in particular seems incredibly >fragile, and I've been fighting with build systems for bug-squashing >NMUs all weekend. Still, it's your package...) Thanks for the critique. copyright-check.mk being fragile is a known issue, with a pending fix in the form of a reimplementation of that cdbs snippet. I would appreciate if you could elaborate on other things your found problematic about my cdbs setup - I might learn something here :-) I would also appreciate if you could find time to look at that new copyright-check.mk routine. >> And would you perhaps be interested in helping maintain this package >> in the future? I would be happy to grant you write access to the VCS >> used for the packaging, if you are interested. > >I'm in collab-maint already (I have a package in bzr there), but to be >honest my only interest in libgtkol is that it had a release-goal bug >that looked easy! I didn't realise at that point that I'd be filing and >fixing an RC bug as a result... Ahh - then you could've just applied your patch directly through SVN. Why didn't you - especially now after I shoed positive interest in your work? I deliberately placed it in collab-maint in order to make it easy for others to help out, and also myself to the LowThresholdNMU list at the Debian wiki. If you feel I could do more to promote my interest in random direct help, please tell me! - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH+dmFn7DbMsAkQLgRAnAbAJ4iwoCAdhIv3/FWiWRk3GH7NxT/4gCfb+XC T9/tDc1vL/lXoExyEKVwjnc= =TzRW -END PGP SIGNATURE-
Bug#474615: libgtkol: contains binaries without source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Apr 08, 2008 at 09:33:10PM +0100, Simon McVittie wrote: >Version: 1.4.1+dfsg1-1 > >^ seems you forgot to close the bug in your upload, so, doing that Thanks for noticing. And fixing. >On Mon, 07 Apr 2008 at 10:21:25 +0200, Jonas Smedegaard wrote: >> On Sun, Apr 06, 2008 at 10:15:37PM +0100, Simon McVittie wrote: >> >I'm in collab-maint already (I have a package in bzr there), but to be >> >honest my only interest in libgtkol is that it had a release-goal bug >> >that looked easy! I didn't realise at that point that I'd be filing and >> >fixing an RC bug as a result... >> >> Ahh - then you could've just applied your patch directly through SVN. >> Why didn't you - especially now after I shoed positive interest in your >> work? > >Committing to the VCS of a package I have no particular involvement or >interest in, without any patch review from the maintainer who knows how it >works, seemed rather rude (perhaps this is an attitude I've picked up from >work, where for QA reasons even the main maintainer for a package doesn't make >non-trivial merges to HEAD without someone else reviewing the branch). > >In collab-maint, in particular, commit access is given out more or less >indiscriminately (as a non-DD, I got it by asking if I could put my package >there) so just because I'm in the collab-maint group doesn't seem to me to be >enough "excuse" to commit to other people's repositories. Perhaps I >should have committed my NMU to a branch for your consideration, but >svn branches are annoying :-) Thanks for elaborating. My lesson from this is then to explicitly welcome messing directly with VCS for my packages. I inspect what goes in, even stuff done by co-maintainers (also to learn from the style of changes). Oh - and with my latest upload the packaging switched to my new pet VCS, Git. Branching is cheap there ;-) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH+9sjn7DbMsAkQLgRAuj2AJ9DOi+kZu3oRl8j3A8Y8sSjkELY9wCfdHp6 TuMhpHAwmflK0LOa4KLLToo= =i1MK -END PGP SIGNATURE-
