[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11



On Sun, Feb 07, 2016 at 08:40:10PM +0000, Jose M Calhariz wrote:
> On 06/02/16 23:41, Mattia Rizzolo wrote:
> > Umh, couldn't you turn d/rules to use the dh sequencer?
> 
> I don't know enough and lintian show many problems with upstream d/rules.

well, let's fix them, then :)
Attached there is a d/rules using short dh, may you try it and bend it
better to the needs of this package?
There are some errors, for example lintian complains about
dependency_libs in the .la files [0], and other stuff.
though it also fixes things like debian-changelog-file-missing and
no-copyright-file I otherwise have with the current rules file.
Another thing: the build log looks really different, there are way more
lisp-related lines, but I haven't looked at it at all.
And it's really untested and I think it would enjoy some more work.

> > I anyway see a lot of nowadyas obsolete stuff that could really easily
> > be removed, for example:
> >
> > * all that if/else/endif staff can go away if you stop calling manually
> >   ./configure and rely in dh_auto_configure
> 
> Done

though you didn't remove the if/else/endif at the start of d/rules.

> > * the source targe should follow policy §4.9 (so, named get-orig-source)
> 
> Removed, not usefull for me.

cool.

> > * d/changelog
> >   + "Remove upstream debian directory." => what's this?  do you mean the
> >     upstream tarball and you removed it?  source fomat 3.0 already does
> >     it by itself, i don't understand what you did.
> 
> I created a commit in git that removes the upstream debian directory. 
> Maybe is not necessary.

umh now I don't recall if gbp does the wrong thing while importing the
ustream tarball and do things wrong, but I hope it doesn't.  Anyway,
that's a kind of thing that is not thought to be in d/changelog.

> > * d/control
> > * maybe you can consider to drop the -dbg package in favour of the
> >   automatically built dbgsym?
> Done

cool!

> > * d/menu: drop it?
> Why?

https://lintian.debian.org/tags/command-in-menu-file-and-desktop-file.html

> > * d/copyright: consider write a copyright-format 1.0 one?  at a first
> >   sight doesn't look too much work.
> Done

though it's not compliant, and indeed lintian is noisy on it, please try
to figure out what's wrong with it and fix it.
I believe blindly following lintian here is enough, though it would be
nice if you could understand what's the problem by yourself :)

> > * once fixed the b-d, I get another ftbfs, with a lisp backtrace ending:
> >   'error--> (file-error "No such file or directory" "rep/data/tables")'
> >   go figure...
> Are you building in i386 or amd64?

amd64.
though now it builds, umh.  ok...

> > * so it seems you have symlinked doc dir.  do as it pleases you, but
> >   anyway please drop those manually built .postinst file if their only
> >   use it that one.
> Droped

I haven't yet checked, though you need to make sure there is an upgrade
path, and remember that dpkg doesn't overwrite a symlink while
installing/upgrading a package.  do you remember those symlink_to_dir
and dir_to_symlink thinghies of the other package?

> > * please try to get a reproducible buildable package, from what I see it
> >   wouldn't be difficult at all.
> >
> > there are 57 open bugs, are you telling me none of them get closed by
> > this upload? :\
> > I anyway expect some bug triaging done…
> Will do it.


* d/clean: you are removing config.sub, config.guess, configure and
  libtool.  Well,
  1) theoretically once the package is built the clean target of d/rules
     should bring the tree back to the original state.
  2) it makes git unnecessarly noisy about deleted files from the tree.
  Just removing those 4 files from the d/clean file is enough, and
  anyway I don't understand what would have been the whole point of
  having them listed there in the first place.

* P: sawfish-lisp-source: maintainer-script-without-set-e postinst
  + and more like that
* d/rules: please try enabling the hardening build flags



[0] add here a random rant about static libaries...... can't we just
    drop them... :\   (last time I brought this up others said to keep
    them for our users...... gah!)
-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  http://mapreri.org                              : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
#!/usr/bin/make -f

export DH_VERBOSE=1

DEB_CFLAGS_MAINT_APPEND := -Wall -fno-strict-aliasing

%:
	dh $@ --parallel --with autoreconf


override_dh_auto_build:
	# Get rid of rpath
	set -e; \
	 tmpfile=`mktemp`; \
	 sed "s/^REP_LIBS=\(.*\)-Wl,--rpath -Wl,[^ ]* \(.*\)$$/REP_LIBS=\1 \2/" Makedefs >$$tmpfile ;\
	 mv $$tmpfile Makedefs
	dh_auto_build -O--parallel

overrid_dh_auto_install:
	dh_auto_install -O--parallel
	# Fixup libdir in .la files
	find debian/tmp -name \*.la | while read file; do \
	  libdir=`echo $$file | sed -e 's@debian/tmp\(.*\)/[^/]*la$$@\1@' `; \
	  tmpfile=`mktemp`; \
	  sed "s@^libdir=.*@libdir='$$libdir'@" $$file >$$tmpfile; \
	  mv $$tmpfile $$file; \
	done

	# Remove info files installed by Makefile. dh_installinfo will do it again without creating info.dir
	find debian -type d -name info | xargs rm -rf
	#empty dependency_libs file in la files
	find debian/tmp/usr/lib -name *.la | xargs \
		sed -i "/dependency_libs/ s/'.*'/''/"


override_dh_install:
	[ ! -f debian/sawfish-lisp-source.install ] || rm debian/sawfish-lisp-source.install
	find debian/tmp/usr/share/sawfish/lisp -name \*.jl | \
	 cut -d/ -f3- | grep -v 'autoload\|custom-defaults' > debian/sawfish-lisp-source.install

	cp debian/sawfish-data.install.in debian/sawfish-data.install
	find debian/tmp/usr/share/sawfish/lisp -name \*.jlc | \
	 cut -d/ -f3- | grep -v 'main' >> debian/sawfish-data.install

	#dh_install --fail-missing
	dh_install --list-missing

Attachment: signature.asc
Description: PGP signature


Reply to: