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

RFS: stumpwm (updated package)

Hi Luca!

On Thu, Aug 12, 2010 at 05:13, Luca Capello <luca at pca.it> wrote:
> Sure, I would have liked to orphan it a *long* time ago (I switched back
> to Ratpoison after +/- 5 years with StumpWM), but as usual I got busied
> with Real Life issues.
> Please note that at some point last year Ramkumar Ramachandra (Cc:ed)
> also showed interest in the StumpWM Debian package, you may want to
> coordinate with him any future upload.

Ramkumar Ramachandra has dropped stumpwm.  I will adopt it.

>> > Some "problems":
>> > 2) I am not so familiar with source-format-3.0, but AFAIK you must not
>> > depend on quilt anymore, if you do not specifically use quilt in
>> > debian/rules. ?Which means that every quilt usage except
>> > applying/removing patches in debian/rules is useless, but *again* I am
>> > not familiar with source-format-3.0...
>> I haven't touched debian/rules, so it still depends on quilt.
> Mmm, I fail to get why in such case you still want to build-depend on
> quilt. ?If we use quilt for simple-patch management, then
> source-format-3.0(quilt) already manages that, without any extra
> build-dependency except "dpkg (>=". ?Please note that having
> less build-dependency is a good thing, because, for example, the buildds
> (and others, e.g. pbuilder) need less packages to be installed.
> At the same time, if you switch to source-format-3.0(quilt), you also
> need to remove debian/README.source and document each patch as for
> DEP-3, please check <http://wiki.debian.org/Projects/DebSrc3.0>.
> BTW, these are not complaints, I actually want to understand why you
> half-switched to source-format-3.0(quilt) ;-)

Since I simply use 'pdebuild' without any options of pdebuild itself
and dpkg (they are too long and complex), I have to change the source
format to 3.0(quilt) so that dpkg-source will not put .git/* into the
original tarball.  My original purpose is that I plan to upgrade the
patches in the next versions so that I can release a new version as
soon as possible.

> Sure, while doing it directly from the Git repository I indirectly found
> a problem with debcheckout <http://bugs.debian.org/592660> :-(
> Moreover, since I use git-buildpackage, I added to the repository a
> minimal debian/gbp.conf, so git-buildpackage work by default without any
> change (it can be also useful for automatic builds):
> http://git.debian.org/?p=pkg-common-lisp/stumpwm.git;a=commitdiff;h=33aebb0412884323eede4849677a0dd361b8a809
> Doing that, I set the distribution to "UNRELEASED" to avoid any faulty
> upload to Debian (dput will wine if you try to upload a package with
> that distribution) and also unfinalized the debian/changelog entry.
> This last point is still controversial, given that there are different
> workflows <http://bugs.debian.org/517973>. ?However, my point in this
> being that I would prefer you to finalize the package.

OK, It will be finalized after our discussing.

> Given the quality of your work on StumpWM (I have not checked the other
> packages you maintain, sorry) and your responsiveness, reading the
> Debian packaging documentation (Policy, Developer Reference & Co.)
> should not be too difficult, right? ?Feel free to ask for any question
> you have, a better list would be debian-mentors@, but if your questions
> are Common Lisp-specific, this list is fine as well.
> Thank you for stepping in taking care of Common Lisp in Debian.

I have read the social contract, DFSG and DMUP.  Can I apply now?


Reply to: