Re: RFR: webalizer - web server log analysis program
On Fri, Jan 28, 2011 at 09:15:37AM +0100, Sandro Tosi wrote: Hi, let's restart from scratch, concentrating on the packaging side of the story. OK, Also added Felipe in CC. On Thu, Jan 13, 2011 at 22:53, Julien Viard de Galbert jul...@vdg.blogsite.org wrote: Dear mentors and mentees, I am looking for reviews for my package webalizer The previous maintainer Felipe Augusto van de Wiel (faw) agreed that I take over the package, also as he his really busy and this package will be targeting experimental (due to the freeze) I'd like the package to be really polished before asking him for sponsorship. My packaging work is currently on collab-maint: http://git.debian.org/?p=collab-maint/webalizer.git;a=summary I already got the help of Pim van den Berg on the logio patch. So more attention is needed on other patches especially the TTF patch and the gettext patches. What exactly do you feel is need to be checked on those 2 patch series? Those patches did not just apply well from the previous packages so there was some work. (It was the same for logio and Pim van den Berg pointed a few mistakes I did, so thanks). I just imported the TTF patch again and unless I did the same mistakes again I ended up with an equivalent patch, so I guess this one is OK. Let's concentrate on the gettext support. Upstream has a way to select the language at compile time _only_. This patch uses gettext to provide translations at run time. With all the changes upstream the original patch mostly did not apply. But fortunately the patch header included a description on how the patch was build. This involved a script that basically parse the C header for English from upstream and replace the original text variable by the actual text enclosed in a gettext call. The patch also included some code change and the po files. What I did: * I did move most of the changes to the code in a separate patch: 23_gettext_first_part.diff This patch also create a slightly modified version of the script. * The second patch 24_gettext_generated.diff is basically generated by running the script. * Finally the patch 25_gettext_po_files.diff adds the updated po directory. So adding or fixing po files can be done separately. This patch was the most complicated to port, that's why I'm asking for reviews. The other option is probably to push the package to experimental and wait for user feedback ;) Best Regards, -- Julien Viard de Galbertjul...@vdg.blogsite.org http://silicone.homelinux.org/ jul...@silicone.homelinux.org GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6 signature.asc Description: Digital signature
Re: RFR: webalizer - web server log analysis program
Hi, let's restart from scratch, concentrating on the packaging side of the story. On Thu, Jan 13, 2011 at 22:53, Julien Viard de Galbert jul...@vdg.blogsite.org wrote: Dear mentors and mentees, I am looking for reviews for my package webalizer The previous maintainer Felipe Augusto van de Wiel (faw) agreed that I take over the package, also as he his really busy and this package will be targeting experimental (due to the freeze) I'd like the package to be really polished before asking him for sponsorship. My packaging work is currently on collab-maint: http://git.debian.org/?p=collab-maint/webalizer.git;a=summary I already got the help of Pim van den Berg on the logio patch. So more attention is needed on other patches especially the TTF patch and the gettext patches. What exactly do you feel is need to be checked on those 2 patch series? Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikTZjcsENKG=0ipuwzqnoecrufrfbyvhofv4...@mail.gmail.com
Re: RFR: webalizer - web server log analysis program
On 01/15/2011 03:54 AM, gregor herrmann wrote: I don't agree here; I've seen and been involved in quite a few maintainer handovers that worked perfectly without involving the BTS. Of course if the new maintainer needs a sponsor, the sponsor will want to see some proof of the old maintainer's admission. Which is what I am asking here!!! Jonathan talked about a private email. I wont sponsor an upload that would take-over the package just based on that. Just out of curiosity: I am very familiar with Git, it's just that normally, we use upstream-sid / debian-sid, I'm rather unfamiliar with git but sometimes I stumble over packages maintained in git anway; and I haven't seen upstream-sid and debian-sid branches yet. Who/where (team, tool, ...) is this schema used? I first tried to do my packaging trying to integrate with the work of the pkg-php team. I maintain lots of php-* (PEAR packages), and that is what Raphael Geissert and others advised me to do. Given the way I was replied to (rather con-descendent) I thought I was a silly guy not to know that fact, and I thought it was a general habits inside Debian. According to what I have just read here, there's no real rules, and (like often in Debian), the reality is just a big mess. Anyway, using a pristine-tar branch and a debian branch seems not enough to me, whatever naming scheme we choose, because we need to track changes for all flavor of Debian. Using stable or old-stable doesn't seem really a good naming scheme, because when a new version of Debian is released, the meaning changes. So using lenny, squeeze, sid, rather than old-stable, stable, testing, unstable, seems more accurate to me. Which leads again to use: - upstream-sid / debian-sid - upstream-squeeze / debian-squeeze - upstream-lenny / debian-lenny as branch names, which avoids any kind of possible confusion (and doesn't forces you to act upon a new Debian release). Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d31b1b9.1070...@debian.org
Re: RFR: webalizer - web server log analysis program
On 01/15/2011 02:02 AM, Julien Viard de Galbert wrote: I didn't want to offense you in any way by saying you might not be familiar with git. I'm sorry if it sounded like that... Did it sound like I was offended ? I was not! :) I see your point with branch names. But I don't think there is a real consensus on the naming, for instance the X strike force name them debian-unstable, upstream-unstable (and same with -experimental). Well, calling it debian-unstable or debian-sid is the same to me. The point is having a branch per version of Debian ! And the first reference I read: git-buildpackage's documentation 'just' use master, upstream and pristine-tar. Ok. Certainly, but I really have no idea here. Maybe we could check some versions: I'm using debhelper 8.0.0, dh-autoreconf 2 and autoconf 2.67-2. This is the exact versions I have as well on my laptop. Do you have any other idea to tackle this ? I don't know. The thing is, if I do a fresh install, or use pbuilder, it might work, but I'd like to find out what's going on. I'll try to investigate more and I will let you know. Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d31b232.5000...@debian.org
Re: RFR: webalizer - web server log analysis program
On Sat, 15 Jan 2011 22:39:53 +0800, Thomas Goirand wrote: On 01/15/2011 03:54 AM, gregor herrmann wrote: I don't agree here; I've seen and been involved in quite a few maintainer handovers that worked perfectly without involving the BTS. Of course if the new maintainer needs a sponsor, the sponsor will want to see some proof of the old maintainer's admission. Which is what I am asking here!!! Jonathan talked about a private email. I wont sponsor an upload that would take-over the package just based on that. Ok, I agree in this case; until now I got the impression that you were talking about handing over maintainership in general. Maybe our confusion comes from the fact that Jonathan seems to ask about a _review_ (and not an upload) and you were already thinking about potential spnsorship in the future? I'm rather unfamiliar with git but sometimes I stumble over packages maintained in git anway; and I haven't seen upstream-sid and debian-sid branches yet. Who/where (team, tool, ...) is this schema used? I first tried to do my packaging trying to integrate with the work of the pkg-php team. I maintain lots of php-* (PEAR packages), and that is what Raphael Geissert and others advised me to do. I see, thanks! Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Queen: Let Me Entertain You signature.asc Description: Digital signature
Re: RFR: webalizer - web server log analysis program
On 01/16/2011 01:24 AM, gregor herrmann wrote: Maybe our confusion comes from the fact that Jonathan seems to ask about a _review_ (and not an upload) and you were already thinking about potential spnsorship in the future? Yes, I am making the proposal to be the sponsor, because I need the package to be in good shape as well. Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d31e287.1040...@debian.org
Re: RFR: webalizer - web server log analysis program
On 01/14/2011 05:53 AM, Julien Viard de Galbert wrote:
Dear mentors and mentees,
I am looking for reviews for my package webalizer
The previous maintainer Felipe Augusto van de Wiel (faw) agreed that
I take over the package, also as he his really busy and this package
will be targeting experimental (due to the freeze) I'd like the package
to be really polished before asking him for sponsorship.
My packaging work is currently on collab-maint:
http://git.debian.org/?p=collab-maint/webalizer.git;a=summary
I already got the help of Pim van den Berg on the logio patch.
So more attention is needed on other patches especially the TTF patch
and the gettext patches.
Any comment on general packaging are also appreciated.
Thanks for your time.
Hi,
First of all, thanks for your interest in Webalizer. I'm a heavy user
of it, and it's nice that you seem to want to take over the maintenance
of this left-over. Let me give few comments...
From your changelog:
* New maintainer.
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).
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.
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.
Then, I tried to build your package and it fails:
dh_autoreconf
/usr/share/aclocal/dotconf.m4:5: warning: underquoted definition of
AM_PATH_DOTCONF
/usr/share/aclocal/dotconf.m4:5: run info '(automake)Extending aclocal'
/usr/share/aclocal/dotconf.m4:5: or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
configure.in:37: warning: AC_TRY_RUN called without default to allow
cross compiling
autoconf: Undefined macros:
configure.in:322: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])
configure.in:37: warning: AC_TRY_RUN called without default to allow
cross compiling
autoconf: Undefined macros:
configure.in:327: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])
configure.in:37: warning: AC_TRY_RUN called without default to allow
cross compiling
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
IMHO, the old format 1.0 was fine, and unless you really know what
you are doing, and do it well, keep it. :)
Let me know when you have fixed the above issue, and I'll look further.
Thomas
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d30103d.5070...@debian.org
Re: RFR: webalizer - web server log analysis program
On Fri, Jan 14, 2011 at 04:58:37PM +0800, Thomas Goirand wrote:
[...]
Hi,
Hello,
First of all, thanks for your interest in Webalizer. I'm a heavy user
of it, and it's nice that you seem to want to take over the maintenance
of this left-over. Let me give few comments...
Thanks for looking at it !
From your changelog:
* New maintainer.
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...
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
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 ;)
Then, I tried to build your package and it fails:
dh_autoreconf
/usr/share/aclocal/dotconf.m4:5: warning: underquoted definition of
AM_PATH_DOTCONF
/usr/share/aclocal/dotconf.m4:5: run info '(automake)Extending aclocal'
/usr/share/aclocal/dotconf.m4:5: or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
configure.in:37: warning: AC_TRY_RUN called without default to allow
cross compiling
autoconf: Undefined macros:
configure.in:322: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])
configure.in:37: warning: AC_TRY_RUN called without default to allow
cross compiling
autoconf: Undefined macros:
configure.in:327: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])
configure.in:37: warning: AC_TRY_RUN called without default to allow
cross compiling
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 ?
IMHO, the old format 1.0 was fine, and unless you really know what
you are doing, and do it well, keep it. :)
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 ;)
Let me know when you have fixed the above issue, and I'll look further.
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.
Best Regards,
--
Julien Viard de Galbertjul...@vdg.blogsite.org
http://silicone.homelinux.org/ jul...@silicone.homelinux.org
GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net
Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6
signature.asc
Description: Digital signature
Re: RFR: webalizer - web server log analysis program
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 -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Queen: Innuendo signature.asc Description: Digital signature
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
Re: RFR: webalizer - web server log analysis program
In 4d307440.30...@debian.org, Thomas Goirand wrote: 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. It should be. The bugs types are for when communication needs to occur on a wider scale, particularly with the wnpp team. We don't *have to* add something a b.d.o for every bug fixed by upstream, or each lintian error / policy violation cleaned; we also don't *require* one for changes in package ownership. 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. Well, if the old maintainer agrees, they should do the initial sponsorship. If for some reason they can't; the private email does need to be disclosed to (at least) the DD that does the actual sponsoring. We do need to respect the work of existing maintainers; part of that is not stealing a package from them. We do what is necessary to prevent that. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFR: webalizer - web server log analysis program
On Sat, Jan 15, 2011 at 12:05:20AM +0800, Thomas Goirand wrote:
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?
[...]
OK, OK, I'll ask Felipe to orphan it.
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 didn't want to offense you in any way by saying you might not be
familiar with git. I'm sorry if it sounded like that...
I see your point with branch names.
But I don't think there is a real consensus on the naming, for instance
the X strike force name them debian-unstable, upstream-unstable
(and same with -experimental).
And the first reference I read: git-buildpackage's documentation 'just'
use master, upstream and pristine-tar.
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
Well on some Teams, people prefer working on the VCS directly, but OK
I'll provide a .dsc later.
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)
OK, if Felipe no longer have time for it, that's a good news for
webalizer.
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?
If you insist, I really didn't think this could be that important...
I'll drop a word upstream too.
But first, if you don't mind, let's try to understand the build issue:
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.
Yeah, right, read too fast, It's a warning and installing libdotconf-dev
only adds the warning, it still builds.
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
Re: RFR: webalizer - web server log analysis program
On Sat, 15 Jan 2011 00:05:20 +0800, Thomas Goirand wrote: 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. Everybody does it, why should you be an exception? I don't agree here; I've seen and been involved in quite a few maintainer handovers that worked perfectly without involving the BTS. Of course if the new maintainer needs a sponsor, the sponsor will want to see some proof of the old maintainer's admission. But if -- like it might be in this case -- the old maintainer is the sponsor or the new maintainer uploads himself or herself there's no problem whatsoever IMO. 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. 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? RFA and O bugs are for situations when the old maintainer wants to stop the task and there isn't yet a new maintainer. We need to keep things with a public record, otherwise we are risking take-overs. Doesn't seem to be a recurrent problem ... Just out of curiosity: I am very familiar with Git, it's just that normally, we use upstream-sid / debian-sid, I'm rather unfamiliar with git but sometimes I stumble over packages maintained in git anway; and I haven't seen upstream-sid and debian-sid branches yet. Who/where (team, tool, ...) is this schema used? Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Rocky Hill Johnny Winter: Bad Girl Blues signature.asc Description: Digital signature
RFR: webalizer - web server log analysis program
Dear mentors and mentees, I am looking for reviews for my package webalizer The previous maintainer Felipe Augusto van de Wiel (faw) agreed that I take over the package, also as he his really busy and this package will be targeting experimental (due to the freeze) I'd like the package to be really polished before asking him for sponsorship. My packaging work is currently on collab-maint: http://git.debian.org/?p=collab-maint/webalizer.git;a=summary I already got the help of Pim van den Berg on the logio patch. So more attention is needed on other patches especially the TTF patch and the gettext patches. Any comment on general packaging are also appreciated. Thanks for your time. -- Julien Viard de Galbertjul...@vdg.blogsite.org http://silicone.homelinux.org/ jul...@silicone.homelinux.org GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6 signature.asc Description: Digital signature
