Re: RFS: wmaker (try 2)
please, see the comments to your mail below. IMO this comments are fine,
but there are more important things:
1. Can you sponsor me to upload the package?
2. What do you think about libwmaker0-dev?
About 1, if the reply is yes, I will upload the changes to mentors ASAP.
About 2 The current wmaker (0.92) includes the library liwmaker0-dev.
This library was removed from upstream, but is used to build two old
packages (wterm, fsviewer). I tried to contact with the maintainers
without success. I think that the best is create a transition for these
Now, is time to prepare the dinner. In three hours (GMT+1) we will leave
Happy New Year 2012!!!
On 31/12/11 18:15, Scott Howard wrote:
> On Fri, Dec 30, 2011 at 12:59 PM, Rodolfo kix Garcia <firstname.lastname@example.org> wrote:
>> About 1: I don't know what to do. I can maintain the current code or change
>> to new debhelper and compat.
> Your choice. I'd say maintain current code, no need to bump the
> version unless you really need some feature.
Ok, then I will continue in this version. I won't make changes about
debhelper and compat.
> I never used those flags because all of my packages used
> dh_auto_configure. Another advantage of dh_auto_configure is that if
> policy changes (or default configure build flags), dh_auto_configure
> will take care of it for you. You can look into if dh_auto_configure
> will work for you, I don't know too much about the options you're
> passing it, but maybe it will.
>> About 3: Jakub sent a comment about it. What should I do?
> I think Jakub and I agree that if you're using simple dh rules, you
> probably can use --with autotools-dev to take care of the
> config.sub/config.guess files properly.
I won't change it now. My priority is upload a new wmaker-0.95 to
debian. The current debian/rules (0.92) is bigger than the new one (0.95).
>> About 4: Yes, debian folder has a lot of files. I moved some of them to one
>> directory in the last upload. I leave it here because I sent a patch to the
>> wmaker-crm upstream (http://lists.windowmaker.org/dev/msg02488.html), but is
>> not applied yet.
> The comment was more about the override_dh_clean target. I was just
> pointing out an alternative to overriding the dh_clean target is to
> use a debian/clean file (see the manpage of dh_clean). You can chose
> either way of doing it, up to you.
I try to solve the problem in the upstream, else, make a patch.
Today I wrote a mail to the maintainer and the patch is upstream:
For this reason, I will keep the override_dh_clean in the rules file.
When the change will be applied to the master branch (now is at next), I
will delete these lines.
>> About 5: Perfect. I will update the next version
>> About 6: The debian folder is included in the upstream, because is used to
>> make the nigthly packages. I am not sending the changes to the upstream yet
>> to avoid disturb the mail list. I am waiting to upload the package to
>> debian, and then send only one patch to the upstream.
> It's ok to have a separate VCS just for debian packaging .
> Upstream's VCS is for their development, you can have your own VCS
> which is for packaging. Even if upstream is using a VCS, it is
> encouraged to keep your packaging in a VCS as well.
> For example,
Ok, I will think more about this idea. I thought about it in the past,
and I am using a local mercurial repo because are too much changes to
upload to the upstream repo.
> It is very possible that your debian/ will be different than upstream
> debian/ because you two have different goals: your packaging for
> distribution in Debian main and they are packaging for nightly builds.
> Also, it is possible that someone, besides you, will do an NMU at some
The package is ITA, I wrote a lot of mails to debian-mentors,
debian-devel, wmaker-dev about upload this package. Probably a NMU
should contact with me or with the wmaker-dev team before send a NMU. At
this moment, upstream and debian are working in the same direction.
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/