On Fri, 6 Mar 2009 19:57:06 +0100 David García Garzón <dgarcia@iua.upf.edu> wrote: > > David García Garzón <dgarcia@iua.upf.edu> wrote: > > > That's our last try to make those packages ready to get into Debian > > > (~svn12799): > > Ups, maybe a Catalan false friend here. I just realized it could have been > understood as 'i am not trying anymore' instead of 'that's the newer one'. > It was 'the newer one' ;-) Not that desperate yet OK. Thanks for the clarification - it's annoying when maintainers try to "hurry things along" by sounding desperate or as if sponsors and other people on the list are just being too pedantic. A simple language difference is a much simpler explanation. > > The debian/ packaging can be in upstream RCS just not in the tarball(s) > > released by upstream. If the upstream build process cannot cope with > > ignoring certain directories, it may be a good idea to fix to solve > > the "inconvenience". > > If such simple solution is allowed, i will do that in release scripts. Now we > export, tarball, export debian inside, and build source package. We should > then, export, delete debian, tarball, reexport debian and build source > package. Not that hard. It does sound like more work than it should require. The main problem would appear that you are exporting and tarballing the entire export. Isn't there a way your build can generate the tarball directly? I haven't had time to look at the actual package but things like autotools have calls like 'make dist' which ignore all the generated stuff and just do the right thing. debian/ would only be added to such a tarball if mentioned explicitly in one of the Makefiles so it is trivial to remove such a section. Exporting and tarballing will avoid .svn directories, etc., but (as the debian/ directory shows) will end up including files that really don't deserve to be in the upstream tarball. Most builds generate lots of temporary and other status files which you really don't want in the tarball because they encode data that is entirely specific to the build machine. You either need to be very careful with the equivalent of 'make clean' or sort out upstream to have a way of creating the tarball that only includes the critical files that do not change between builds and are not architecture-dependent or dependent on the configuration of one particular machine. A lot of debian packages spend a lot of time cleaning up after inadequate (or stale) upstream build configurations. > Anyway, as the upstream release manager I was serious when I said that this > piece of software can be dropped from this binary release. The plugin that > comes with those helper binaries was an experimental GSoC project that i just > enabled on the last package revision but it was disabled until then, just like > other experimental ones also included in source but not compiled. If dropped, ensure that the reasons are described in the changelog. > > > So, what to do now? anything else? are the packages ready be uploaded by > > > an sponsor? > > > > Not by me. Let me just clarify that too - it's because I don't generally sponsor packages using C++ which in turn is because most of those are KDE apps and I don't use KDE (hate it with a passion). See http://people.debian.org/~codehelp/#lang > Ok, but I would like to receive more feedback about any other issues in the > current revision of those packages. If those you say are the only problems i > will be pretty happy, I could build valid debian packages in short. But taking > a look back i guess there could be more issues. ;-) What else are we doing > wrong? Right now, I don't have time to review such a large package, especially one using C++. You may or may not be doing anything particularly wrong, it is just that sponsors are volunteers with other priorities and we do what we can but there are quite a lot of packages on mentors that never get a sponsor. Patience is the key - along with a few pings to this list once in a while. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpaOMlvnVKck.pgp
Description: PGP signature