Bug#847314: awstats: add databasebreak support in update.sh

Vincas Dargis

unread,

Dec 7, 2016, 4:10:02 AM12/7/16

to

Package: awstats
Version: 7.5+dfsg-1
Severity: normal

Dear Maintainer,

Awstats has `databasebreak` parameter witch which user can access to statistic
per day basis, for example, instead only by month due to current defaults.

update.sh currently has two parameters set, with no possibility to apply
`-databasebreak=...`:
-config=$c \
-update >$ERRFILE 2>&1

It would be useful to have a way to define databasebreak’s inside
/etc/default/awstats file, to generate possibly multiple data files per config
file (for every break). Later, user could set `awstats.cgi?databasebreak=day`
cgi argument to access that data. By default, if no `AWSTATS_DATABASE_BREAK` is
set in defaults file, it should not apply `-databasebreak` argument to keep
backwards compatibility.

Looking forward for Maintainers comments.

-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages awstats depends on:
ii perl 5.24.1~rc4-1

Versions of packages awstats recommends:
ii coreutils 8.25-2+b1
ii libnet-xwhois-perl 0.90-4

Versions of packages awstats suggests:
ii apache2 [httpd] 2.4.23-8
pn libgeo-ipfree-perl <none>
pn libnet-dns-perl <none>
pn libnet-ip-perl <none>
ii liburi-perl 1.71-1

-- no debconf information

Sergey B Kirpichev

unread,

Dec 7, 2016, 6:10:02 AM12/7/16

to

severity 847314 wishlist
thanks

On Wed, Dec 07, 2016 at 11:03:47AM +0200, Vincas Dargis wrote:
> Awstats has `databasebreak` parameter witch which user can access to statistic
> per day basis, for example, instead only by month due to current defaults.
>
> update.sh currently has two parameters set, with no possibility to apply
> `-databasebreak=...`:
> -config=$c \
> -update >$ERRFILE 2>&1
>
> It would be useful to have a way to define databasebreak’s inside
> /etc/default/awstats file, to generate possibly multiple data files per config
> file (for every break). Later, user could set `awstats.cgi?databasebreak=day`
> cgi argument to access that data. By default, if no `AWSTATS_DATABASE_BREAK` is
> set in defaults file, it should not apply `-databasebreak` argument to keep
> backwards compatibility.

Sounds interesting, feel free to provide the patch.

Vincas Dargis

unread,

Dec 10, 2016, 5:30:02 AM12/10/16

to

2016.12.07 12:58, Sergey B Kirpichev wrote:
> Sounds interesting, feel free to provide the patch.

Could you hint me the proper way to produce patch?

I image I should install Debian Jesting virtual machine, checkout latest source package... do changes in update.sh,
build & install package, test, and then generate diff with git, attach here?

Thanks.

Sergey B Kirpichev

unread,

Dec 10, 2016, 7:40:03 AM12/10/16

to

On Sat, Dec 10, 2016 at 12:24:00PM +0200, Vincas Dargis wrote:
> Could you hint me the proper way to produce patch?
>
> I image I should install Debian Jesting virtual machine, checkout latest
> source package... do changes in update.sh, build & install package, test,
> and then generate diff with git, attach here?

If you are member of the alioth group collab-maint (feel free to
join) - you also can just commit your changes. Please use common sense and
standard practice for that (i.e. one logical change per commit,
good commit messages).

There is RFA bug #755797 - so feel free to join package maintenance or
take over package maintenence. I'll try to help you as best, as I can.

Regarding tests - probably, you can also test update.sh on live version with
Jessie's version (update.sh has no changes, but I don't remember if
databasebreak switch is working on that version). But in general - yes.
You need some testing setup, e.g. in VM.

Vincas Dargis

unread,

Dec 10, 2016, 9:30:03 AM12/10/16

to

2016.12.10 14:35, Sergey B Kirpichev wrote:
> On Sat, Dec 10, 2016 at 12:24:00PM +0200, Vincas Dargis wrote:
> If you are member of the alioth group collab-maint (feel free to
> join) - you also can just commit your changes.

No I am not, I do not know what's that "collab-maint" or how to join it.

> There is RFA bug #755797 - so feel free to join package maintenance or
> take over package maintenence. I'll try to help you as best, as I can.

Sadly, it seems I only have energy for some bug reports and minor patches
here and there; package maintenance would be over my head.

So in retrospect, would you find some time to review/accept my patch, or
should I use some other channels (such as that collab-maint, whatever that
means :-) ).

Thanks.

Sergey B Kirpichev

unread,

Dec 10, 2016, 12:10:02 PM12/10/16

to

On Sat, Dec 10, 2016 at 04:22:56PM +0200, Vincas Dargis wrote:
> No I am not, I do not know what's that "collab-maint" or how to join it.

It's there:
https://alioth.debian.org/projects/collab-maint/
Just ask admins to join, comment why (i.e. where you would like to
contribute).

(Or, if you prefer, just attach patches to this bug.)

> >There is RFA bug #755797 - so feel free to join package maintenance or
> >take over package maintenence. I'll try to help you as best, as I can.
>
> Sadly, it seems I only have energy for some bug reports and minor patches
> here and there; package maintenance would be over my head.

Not a surprise to me. Package is big and code is messy. Neverless,
any help is welcomed.

> So in retrospect, would you find some time to review/accept my patch, or
> should I use some other channels (such as that collab-maint, whatever that
> means :-) ).

Sure, I'll try. Probably, this can enter next release, but no promises.