Re: RFR: webalizer - web server log analysis program
On 01/14/2011 10:45 PM, Julien Viard de Galbert wrote:
> Well the maintainer has agreed (on private mail) to give it to me, and
> I'm planning to ask him to sponsor it so my understanding was that we
> could avoid the bureaucracy...
>
The way that the previous maintainer would declare that he doesn't
want to maintain would be a RFA (Request For Adoption).
The way you would adopt it would be to do an ITA (Intention To Package)
by renaming his RFA and take-over the ownership of the RFA bug number.
The above 2 are very simple tasks, it's not heavy bureaucracy. You can't
avoid it, as we want everything to be public in Debian. Also, how can we
make sure that you are saying the truth? Well, simply by doing the above. :)
Everybody does it, why should you be an exception?
On 01/14/2011 11:19 PM, gregor herrmann wrote:
> On Fri, 14 Jan 2011 15:45:57 +0100, Julien Viard de Galbert wrote:
>>> If you are adopting the package, then you should close a bug for it
>>> (the package should be orphaned, then the bug should be renamed as
>>> "ITA" (Intention To Adopt), then you should close it in your changelog).
>>>
>> Well the maintainer has agreed (on private mail) to give it to me, and
>> I'm planning to ask him to sponsor it so my understanding was that we
>> could avoid the bureaucracy...
>>
> FWIW: I agree with this point of view.
>
> Cheers,
> gregor
>
>
Exactly since when, a private email is an official document for a change
of maintainership in Debian? What are RFA, O, and ITA for then? I think
you are mistaking Gregor, it's not enough. Now, seeing the activity of the
package (and the fact it hasn't been maintained correctly by the past
maintainer which more or less was MIA), I think that writing a new bug
report giving one week for the old maintainer would be enough, but I
don't think that we can avoid an ITA at least, just based on the pure fact
that the old maintainer "agreed privately"! We need to keep things with
a public record, otherwise we are risking take-overs.
Or maybe I misunderstood, and Gregor agrees with me? :)
>> I tried to do:
>>
>> git checkout -b upstream-sid origin/upstream-sid
>>
>> but it doesn't seem you are using branches. Or am I mistaking with
>> names of the branches you used? Where did you store the .orig.tar.gz?
>> I had to pickup the tgz from upstream, that's not good.
>>
>>
> I'm using the default names for git-buildpackage: upstream and
> pristine-tar.
> git branch -r or looking at the gitweb page should have told you...
> So I guess that maybe you're not familiar with git and would prefer
> that I upload a version to mentors.d.n
>
I am very familiar with Git, it's just that normally, we use upstream-sid /
debian-sid, so that you can have 2 branches per Debian flavor (one for
Lenny, one for Squeeze, one for SID, and eventually one for Experimental,
then you can "git branch" or "git checkout -b" to create a new branch
very easily).
I don't mind using Git, it's very good that you decided to put your own
package on collab-maint, but it would be good if you could as well provide
a link to a .dsc file pre-compiled as well in the future. Anyway, I don't
mind acting as the permanent sponsor for this package if you like :)
(as I really need it to be in good shape for my own usages)
>> Upstream uses 2.23-03 as version name, it seems you renamed it 2.23.03.
>> Why did you do that? If the "-" char is used for Debian, and it's a good
>> thing to have upstream avoiding it (I would strongly recommend you to
>> get it touch with Webalizer authors and let them change that), you can
>> still use it for your package versionning, and produce a 2.23-03-1 in
>> Debian. It's better than renaming it at least, IMHO.
>>
> Well I kept previous maintainers naming on this, even the d/watch file
> is handling the rename properly so I basically didn't change anything
> here ;)
>
Please do. Any words about communicating with upstream about the fact that
his naming scheme isn't so great?
>> Then, I tried to build your package and it fails:
>>
>> [...]
>> autoconf: Undefined macros:
>> configure.in:300:AC_MSG_NOTICE(Done. Type 'make' to continue with build.)
>> configure.in:36:AC_SYS_LARGEFILE
>> configure.in:39:AC_CHECK_DECL(altzone,OPTS="-DHAVE_ALTZONE
>> ${OPTS}",,[#include <time.h>])
>> dh_autoreconf: autoreconf -f -i returned exit code 1
>> make: *** [build] Error 9
>> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>>
>>
> Strange, I've never seen such errors it has always build fine on sid
> either directly or via pbuilder, I'll double check.
> Also I don't have any /usr/share/aclocal/dotconf.m4 file on my system,
> can you check from which package it comes from so that I can test with
> it too ?
>
zigo@GPLHost:buzzig>_ ~$ dpkg -S /usr/share/aclocal/dotconf.m4
libdotconf-dev: /usr/share/aclocal/dotconf.m4
My laptop uses Squeeze. I believe your package should be able to compile
on it as well, right? I don't get it myself... Anyway, what you are
commenting
is a *WARNING*, not the error itself, if I'm not mistaking.
> Well the package had a lot of patches using dpatch so moving to quilt
> was a natural thing to do, now I've learned a lot on using quilt, I will
> not revert back ;)
>
Sure, but fix your dh_autoreconf thing! :)
> I can't reproduce the issue now, so I hope you can either fix it on your
> side or help me to reproduce it.
> Thanks again for your interest in webalizer.
>
Try to install libdotconf-dev then, and see if it's the issue, but I
don't think so.
I don't see why it would fail when it is installed, it sounds strange to
me as well.
There must be something else going on.
Thomas Goirand (zigo)
Reply to: