Hi, [I've added Jean-Philippe in case he wants to weigh in] On Thu, 2016-03-03 at 19:58 +0100, Vincent Auboyneau wrote: > On Thu, Mar 03, 2016 at 03:03:11PM +0000, James Cowgill wrote: > > > The first step is getting compiz back in debian. It has been cleaned up, > > > and polished with the last version of upstream. I have followed the > > > previous advice of Adam Borowski, and set the jpeg and png deps strait. > > Sounds good, assuming it can easily be used with an existing DE in > > Debian (I used to use compiz but I think I've forgotten how it all > > worked). > > The obvious prime target is the mate desktop, which is growing in users, > and has become an official ubuntu flavour, so they recently added a > plugin for better integration. > This is also, according to several professional in this area, the most > accessible desktop available for some impaired users, partly because it > provides stability. Ok I'm fine with compiz being reintroduced into Debian. > > > there is the question of the source format, should it be 3(native) or > > > quilted? > > 3.0 (quilt) > > > > Native is intended for projects developed by Debian itself. These are > > usually infastructure type projects (like dpkg, debhelper, etc). Most > > packages should not be native. > if using quilt, i need to generate a orig.tar.gz, so how'd you proceed > with that? just tar the thing, rename it? In a normal package, the orig.tar.gz should (if possible) be identical to the upstream release version. You probably want this file: https://launchpad.net/compiz/0.9.12/0.9.12.2/+download/compiz-0.9.12.2.tar.bz2 BUT, I have noticed that instead of using patches, Ubuntu has been creating "fake" upstream releases when fixing bugs. This isn't great since the latest bugfixes are now only found in Ubuntu and aren't easily split out for other distributions. The best solution is to try and get a new release of compiz with these fixes and then persuade Ubuntu developers to ship patches in debian/patches rather than manually patching the source. The ideal change flow should be Upstream -> Debian -> Ubuntu. The alternatives to that don't look nice. You could move the diff between ubuntu and upstream into debian/patches, but it looks massive. > > > Another issue, that is pending resolve, is a couple lintian errors: > > > compiz-dev: package-contains-cmake-private-file usr/share/cmake-3.0/FindCompiz.cmake > > > compiz-dev: package-contains-cmake-private-file usr/share/cmake-3.0/FindOpenGLES2.cmake > > > Are those critical? or is it ok till resolution? > > You're not allowed to ship files in /usr/share/cmake-* because that > > directory is internal to cmake. Things will also break when cmake gets > > upgraded - infact what you're doing is already broken in sid. > > > > You should try and use CMake config files if possible, although they > > can be a bit fiddly to setup. For now you could either drop those > > files, or move them to some other directory (which will not > > automatically be searched). > > > > See: > > https://lintian.debian.org/tags/package-contains-cmake-private-file.html > I've already sent a mail to this part's creator, as it is indeed fiddly. Ok, hopefully that can be sorted - it has to be removed for the moment though. > > > As for functionnal tests, compiz is used by ~20 people, and is ready > > > from sid to jessie-backports. > > > I await more instructions and pieces of sound advice, of which i know > > > debian people have plenty. > > > > > > project is uploaded to alioth: > > > https://alioth.debian.org/projects/compiz/ > > > git clone git+ssh://$USER@git.debian.org/git/pkg-a11y/compiz.git > > I've only had a brief look but there a few obvious issues: > > - Needs "de-ubuntifying" (changelogs, control, etc) > I have been told (by a DD) that changelog "mixing" was ok, since ubuntu > was already using it as a project changelog (not just deb changelog), > and debian's additions would only affect last entry. > What do you suggest? OK, in that case leaving those entries should be fine. I did notice the Debian version number is earlier than the Ubuntu version in the changelog which isn't going to work properly - maybe that can be fixed with a new upstream release :) > > - Maintainer field needs sorting out. Who exactly is working on this? > > - Also you don't own the ITP - are you working together? > I work with Jean-philippe yes. we could transfer ownership indeed. You don't need to transfor ownership if everyone involved is ok with what's going on. You should remove the XSBC-Original-Maintainer field, and replace the Uploaders field with the other people working on compiz. Looking over the ITP, two teams were mentioned: pkg-a11y and compiz. If the packaging is being done by a team then the Maintainer field should be set to a sutible mailing list. Has it been decided which team compiz will live under? Relevant policy info: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Maintainer > > - The package cannot be built since these dependencies do not exist > > in Debian. How did you test this on Debian if it cannot be built? > > > > The following packages have unmet dependencies: > > sbuild-build-depends-compiz-dummy : Depends: dh-migrations but it is not installable > > Depends: dh-translations but it is not installable > > Depends: libxorg-gtest-dev but it is not installable > > E: Unable to correct problems, you have held broken packages. > these have been removed, i don't know which repo you pulled, maybe i did > a mistake in a link. > Nevertheless, you can trust git://anonscm.debian.org/pkg-a11y/compiz.git Ah I've just noticed there's a "sid" branch in the git repo and I was using "master" by mistake. Although it's still a draft, this DEP contains some nice guidelines for git packaging, but it's not a requirement to follow it: http://dep.debian.net/deps/dep14/ I would argue at least the default branch should be the main development branch. So the package now builds for me now and there is a long list of lintian warnings you can start looking at (6 errors and 30 warnings - but some are duplicates). A lot of them seem simple to fix. You should try and fix all of them unless it's very difficult. For some more things to try and fix, run this which will show absolutely everything: $ lintian -IE --pedantic --show-overrides James
Attachment:
signature.asc
Description: This is a digitally signed message part