Re: RFS: collectl

2010-03-14 Thread Bernd Schubert 
Hello Tim,

On Tuesday 08 December 2009, Tim Retout wrote:
> If there's no response within a week of your message, I'll be happy to
> just go ahead and sponsor your version.
> 

any chance you could upload collectl?


Thanks,
Bernd


-- 
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/201003150032.11081.bernd.schub...@fastmail.fm

Re: RFS: collectl

2010-01-11 Thread Paul Wise 
On Tue, Jan 12, 2010 at 2:01 PM, Russ Allbery  wrote:

> Hm, isn't the obvious and simple way of implementing this change to just
> create a second class of buildds that do exactly what the current ones do
> but then throw out all the arch-dependent packages and only keep the
> arch-independent ones?  Or even more simply, just designate one
> architecture (i386 perhaps) to keep all the results of the build including
> the arch-independent packages?

Hmm, I guess so.

> That's what I assume was going to happen, which unfortunately doesn't
> imply fixing any of the problems you note.

Aye, we'll see I guess.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2010-01-11 Thread Russ Allbery 
Paul Wise  writes:

> When that change occurs, there will be 2 kinds of buildds; the one that
> builds the arch all and arch any packages and the ones that
> builds. These will obviously be different for different packages, I
> imagine the fastest arches will be chosen for the build-arch independent
> packages. I imagine this will require changes to make the buildds call
> debian/rules build-indep when appropriate and build-arch when not
> appropriate. In any case, there will be a shakeup of buildd behaviour
> with running build/build-indep/build-arch and installing
> build-depends-indep packages so I'm hoping this issue will be fixed to
> be more in line with policy.

Hm, isn't the obvious and simple way of implementing this change to just
create a second class of buildds that do exactly what the current ones do
but then throw out all the arch-dependent packages and only keep the
arch-independent ones?  Or even more simply, just designate one
architecture (i386 perhaps) to keep all the results of the build including
the arch-independent packages?

That's what I assume was going to happen, which unfortunately doesn't
imply fixing any of the problems you note.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2010-01-11 Thread Paul Wise 
On Tue, Jan 12, 2010 at 11:33 AM, Russ Allbery  wrote:

> Doesn't that break regular builds?  Or does calling the binary target then
> clean it up by going back to run build-indep?

The in mapserver back then binary-indep/install-indep targets depended
on build-indep and the buildds call binary-arch. debuild and friends
call debian/rules binary while the buildds call debian/rules
binary-arch. So:

debuild:

build -> build-arch
binary -> binary-arch -> install-arch -> build-arch
 \-> binary-indep -> install-indep -> build-indep

buildd:

build -> build-arch
binary-arch -> install-arch -> build-arch

>> When maintainer-built .debs are finally thrown away and the required
>> handling for arch all packages gets implemented on the buildds, I
>> imagine the buildds will have to change to using build-arch instead?
>
> I'm not sure that I see the connection.

When that change occurs, there will be 2 kinds of buildds; the one
that builds the arch all and arch any packages and the ones that
builds. These will obviously be different for different packages, I
imagine the fastest arches will be chosen for the build-arch
independent packages. I imagine this will require changes to make the
buildds call debian/rules build-indep when appropriate and build-arch
when not appropriate. In any case, there will be a shakeup of buildd
behaviour with running build/build-indep/build-arch and installing
build-depends-indep packages so I'm hoping this issue will be fixed to
be more in line with policy.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2010-01-11 Thread Russ Allbery 
Paul Wise  writes:
> On Tue, Jan 12, 2010 at 9:23 AM, Russ Allbery  wrote:

>> The basic problem is that while there's potentially some use to the
>> idea of separating out architecture-independent build requirements,
>> Lintian wasn't really checking that.  In order to support this, you
>> have to very carefully structure your debian/rules so that the
>> architecture-independent parts aren't run by the buildds.  (Which, at
>> the moment, is actually impossible since the buildds don't use
>> build-arch.)

> It is possible to do that by ignoring policy and having debian/rules
> build depend on build-arch only and not on build-indep.  I remember
> pkg-gis having to do that for mapserver many years ago.

Doesn't that break regular builds?  Or does calling the binary target then
clean it up by going back to run build-indep?

> When maintainer-built .debs are finally thrown away and the required
> handling for arch all packages gets implemented on the buildds, I
> imagine the buildds will have to change to using build-arch instead?

I'm not sure that I see the connection.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2010-01-11 Thread Paul Wise 
On Tue, Jan 12, 2010 at 9:23 AM, Russ Allbery  wrote:

> The basic problem is that while there's potentially some use to the idea
> of separating out architecture-independent build requirements, Lintian
> wasn't really checking that.  In order to support this, you have to very
> carefully structure your debian/rules so that the architecture-independent
> parts aren't run by the buildds.  (Which, at the moment, is actually
> impossible since the buildds don't use build-arch.)

It is possible to do that by ignoring policy and having debian/rules
build depend on build-arch only and not on build-indep. I remember
pkg-gis having to do that for mapserver many years ago. When
maintainer-built .debs are finally thrown away and the required
handling for arch all packages gets implemented on the buildds, I
imagine the buildds will have to change to using build-arch instead?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2010-01-11 Thread Russ Allbery 
Tim Retout  writes:

> This is correct; however, having read bug #552200, I'm not yet
> personally convinced that it deserved to be removed.  If the package
> later added some arch-dependent binary packages, it would be nice to be
> consistent.

The basic problem is that while there's potentially some use to the idea
of separating out architecture-independent build requirements, Lintian
wasn't really checking that.  In order to support this, you have to very
carefully structure your debian/rules so that the architecture-independent
parts aren't run by the buildds.  (Which, at the moment, is actually
impossible since the buildds don't use build-arch.)

All Lintian was looking at was architecture-independent packages, which is
pointless since there's no reason to build an architecture-independent
package unless you want the architecture-independent binary packages.

Even if such a package converted to mixed architecture, chances are this
would immediately mean that everything listed in Build-Depends-Indep is
now required in Build-Depends, so the work that you did to separate them
is now wrong and has to be undone.

> (I think I could envisage an automated Perl package building tool that
> would love to be able to install automatically just the packages needed
> to run the clean rule - I shall write such a script in my copious free
> time and then complain bitterly to the lintian maintainers.)

That's a different problem than Build-Depends-Indep was intended to solve,
though.

In general, I think situations where the only target you want to run is
the clean rule are actually bugs.  In particular, dpkg-source is buggy
(already reported) in that it requires that you run the clean target
before building the source package when doing anything other than an
architecture-limited build.  This is wasted effort when what one is
building a source package from is an export from a VCS, such as with any
of the *-buildpackage tools, and creates an artificial requirement for
packages that have to be installed outside the build chroot just to run
the clean target to create a source package to move into the build chroot.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2010-01-11 Thread Tim Retout 
On Sun, 2010-01-10 at 09:43 +0800, Paul Wise wrote:
> On Sun, Jan 10, 2010 at 9:05 AM, Bernd Schubert
>  wrote:
> 
> > Lintian -pendantic complains with:
> >
> > I: collectl source: build-depends-without-arch-dep bash
> ...
> > I'm not sure what to do about the new "build-depends-without-arch-dep". If I
> > set in the control file "Build-Depends-Indep" it complains about:
> >
> > E: collectl source: clean-should-be-satisfied-by-build-depends quilt
> > E: collectl source: clean-should-be-satisfied-by-build-depends debhelper
> 
> lintian does not have a build-depends-without-arch-dep tag, it was
> removed in the 2.3.0 release.

This is correct; however, having read bug #552200, I'm not yet
personally convinced that it deserved to be removed.  If the package
later added some arch-dependent binary packages, it would be nice to be
consistent.

(I think I could envisage an automated Perl package building tool that
would love to be able to install automatically just the packages needed
to run the clean rule - I shall write such a script in my copious free
time and then complain bitterly to the lintian maintainers.)

The fix is to move bash (>= 4.0) to Build-Depends-Indep, and leave
debhelper and quilt in the Build-Depends field.  It's not a particularly
serious issue, though.

Bernd: Sorry, I'll review your package tomorrow. :)

-- 
Tim Retout 


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2010-01-09 Thread Ben Finney 
Bernd Schubert  writes:

> I just uploaded the new collectl release. 
>
> Lintian -pendantic complains with:
>
> I: collectl source: build-depends-without-arch-dep bash

Paul Wise  writes:

> lintian does not have a build-depends-without-arch-dep tag, it was
> removed in the 2.3.0 release. You should upgrade your version of
> lintian to the latest one:

More generally: Don't upload a package that hasn't been built in an
up-to-date Debian ‘sid’ environment.

-- 
 \   “There's no excuse to be bored. Sad, yes. Angry, yes. |
  `\Depressed, yes. Crazy, yes. But there's no excuse for boredom, |
_o__)  ever.” —Viggo Mortensen |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2010-01-09 Thread Paul Wise 
On Sun, Jan 10, 2010 at 9:05 AM, Bernd Schubert
 wrote:

> Lintian -pendantic complains with:
>
> I: collectl source: build-depends-without-arch-dep bash
...
> I'm not sure what to do about the new "build-depends-without-arch-dep". If I
> set in the control file "Build-Depends-Indep" it complains about:
>
> E: collectl source: clean-should-be-satisfied-by-build-depends quilt
> E: collectl source: clean-should-be-satisfied-by-build-depends debhelper

lintian does not have a build-depends-without-arch-dep tag, it was
removed in the 2.3.0 release. You should upgrade your version of
lintian to the latest one:

http://packages.debian.org/changelogs/pool/main/l/lintian/current/changelog#versionversion2.3.0

> And at least for now I do not plan to fix "hyphen-used-as-minus-sig".

It is easy to do so, just replace - with \- or \(hy as appropriate:

http://lintian.debian.org/tags/hyphen-used-as-minus-sign.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2010-01-09 Thread Bernd Schubert 
Hello Tim,

I just uploaded the new collectl release. 

Lintian -pendantic complains with:

I: collectl source: build-depends-without-arch-dep bash

and 

I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:41


I'm not sure what to do about the new "build-depends-without-arch-dep". If I 
set in the control file "Build-Depends-Indep" it complains about:

E: collectl source: clean-should-be-satisfied-by-build-depends quilt
E: collectl source: clean-should-be-satisfied-by-build-depends debhelper

Bug in lintian? 


And at least for now I do not plan to fix "hyphen-used-as-minus-sig". 


Any chance you could upload the new package?


Thanks,
Bernd







-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RE: RFS: collectl

2010-01-07 Thread Seger, Mark 
So it took me a little longer than I had originally planned, but there were a 
few minor problems to be fixed/tested before doing a new release.  In any event 
the version of collectl on sourceforge now has the new directory tree structure 
which can either be used as-is with debian or if some additional tweaking is 
required it should be fairly minimal, I hope.  If anything more needs to be 
tweaked on my end just let me know...
-mark

>-Original Message-
>From: Bernd Schubert [mailto:bernd.schub...@fastmail.fm]
>Sent: Monday, December 14, 2009 10:31 AM
>To: Seger, Mark
>Cc: Tim Retout; debian-mentors@lists.debian.org
>Subject: Re: RFS: collectl
>
>On Monday 14 December 2009, Seger, Mark wrote:
>> >-Original Message-
>> >From: Tim Retout [mailto:t...@retout.co.uk]
>> >Sent: Monday, December 14, 2009 10:20 AM
>
>> >You don't have to get rid of them necessarily, if they're useful
>> >documentation.
>> >
>> >> - is it ok to keep my utility scripts in /usr/share/collectl/util
>so
>> >> - I don't corrupt /usr/bin with files nobody really ever uses?  The
>> >> - man pages I wrote for them DO include the explicit path so people
>> >> - will know how to find them if they really want to.
>> >
>> >That's probably best, because otherwise we *will* need man pages. :)
>> >
>> >So I'd just make a release, and then you can make another release if
>> >we come back with a huge set of man page fixes or whatever.
>>
>> great.  In that I'm going to remove the manpages since I don't really
>thing
>>  they add any value and the utilities to have a 'usage' output when
>you run
>>  them w/o switches.  I think it also will help keep things simpler.
>>
>> So should I just consider the kit done then and upload it to
>sourgeforge
>>  as-is?
>
>Yes, please. I will then create a new package later on.
>
>
>Thanks,
>Bernd


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2009-12-14 Thread Bernd Schubert 
On Monday 14 December 2009, Seger, Mark wrote:
> >-Original Message-
> >From: Tim Retout [mailto:t...@retout.co.uk]
> >Sent: Monday, December 14, 2009 10:20 AM

> >You don't have to get rid of them necessarily, if they're useful
> >documentation.
> >
> >> - is it ok to keep my utility scripts in /usr/share/collectl/util so
> >> - I don't corrupt /usr/bin with files nobody really ever uses?  The
> >> - man pages I wrote for them DO include the explicit path so people
> >> - will know how to find them if they really want to.
> >
> >That's probably best, because otherwise we *will* need man pages. :)
> >
> >So I'd just make a release, and then you can make another release if
> >we come back with a huge set of man page fixes or whatever.
> 
> great.  In that I'm going to remove the manpages since I don't really thing
>  they add any value and the utilities to have a 'usage' output when you run
>  them w/o switches.  I think it also will help keep things simpler.
> 
> So should I just consider the kit done then and upload it to sourgeforge
>  as-is?

Yes, please. I will then create a new package later on.


Thanks,
Bernd


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RE: RFS: collectl

2009-12-14 Thread Seger, Mark 


>-Original Message-
>From: Tim Retout [mailto:t...@retout.co.uk]
>Sent: Monday, December 14, 2009 10:20 AM
>To: Seger, Mark
>Cc: Bernd Schubert; debian-mentors@lists.debian.org
>Subject: Re: RFS: collectl
>
>On Mon, Dec 14, 2009 at 02:26:54PM +, Seger, Mark wrote:
>> >From: Bernd Schubert [mailto:bernd.schub...@fastmail.fm]
>> >I have to clearly admit, that I don't care if it is a hyphen, dash or
>> >minus,
>> >for me all three are the same. I even don't know which of those three
>is
>> >correct for something link "-s".
>> >If Tim hadn't told me he wants to have lintian --pedantic errors
>fixed
>> >as much
>> >as possible, I probably never would have cared...
>
>I'm not going to insist on the manpage lintian fixes in the first
>upload, if it helps.  They can sometimes take a bit of work/thought to
>get right, and I've not looked at this case in detail.
>
>> I guess I'm a loss of what to do next, if anything.  I haven't been
>doing anything with CVS as collectl is just a couple of scripts.  If it
>would help I could send you a copy of the latest tarball.
>>
>> So right now I guess the big questions for me are:
>> - are the man pages ok the way they are without having to worry about
>explicitly quoting everywhere I use a hyphen?  In fact, my keyboard only
>has a single character, do other keyboards actually differentiate?
>> - I now have 3 more man pages for 3 utilities nobody every would use
>except me and each now references the others.  If this isn't necessary
>I'd be happy to remove them
>
>I doubt this is necessary unless they're installed in /usr/bin/ (or
>similar).  Debian doesn't require manual pages for auxiliary scripts -
>see:
>
>http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1
>
>You don't have to get rid of them necessarily, if they're useful
>documentation.
>
>> - is it ok to keep my utility scripts in /usr/share/collectl/util so
>> - I don't corrupt /usr/bin with files nobody really ever uses?  The
>> - man pages I wrote for them DO include the explicit path so people
>> - will know how to find them if they really want to.
>
>That's probably best, because otherwise we *will* need man pages. :)
>
>So I'd just make a release, and then you can make another release if
>we come back with a huge set of man page fixes or whatever.
>

great.  In that I'm going to remove the manpages since I don't really thing 
they add any value and the utilities to have a 'usage' output when you run them 
w/o switches.  I think it also will help keep things simpler.

So should I just consider the kit done then and upload it to sourgeforge as-is?

-mark


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2009-12-14 Thread Tim Retout 
On Mon, Dec 14, 2009 at 02:26:54PM +, Seger, Mark wrote:
> >From: Bernd Schubert [mailto:bernd.schub...@fastmail.fm]
> >I have to clearly admit, that I don't care if it is a hyphen, dash or
> >minus,
> >for me all three are the same. I even don't know which of those three is
> >correct for something link "-s".
> >If Tim hadn't told me he wants to have lintian --pedantic errors fixed
> >as much
> >as possible, I probably never would have cared...

I'm not going to insist on the manpage lintian fixes in the first
upload, if it helps.  They can sometimes take a bit of work/thought to
get right, and I've not looked at this case in detail.

> I guess I'm a loss of what to do next, if anything.  I haven't been doing 
> anything with CVS as collectl is just a couple of scripts.  If it would help 
> I could send you a copy of the latest tarball.
> 
> So right now I guess the big questions for me are:
> - are the man pages ok the way they are without having to worry about 
> explicitly quoting everywhere I use a hyphen?  In fact, my keyboard only has 
> a single character, do other keyboards actually differentiate?
> - I now have 3 more man pages for 3 utilities nobody every would use except 
> me and each now references the others.  If this isn't necessary I'd be happy 
> to remove them

I doubt this is necessary unless they're installed in /usr/bin/ (or
similar).  Debian doesn't require manual pages for auxiliary scripts -
see:

http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1

You don't have to get rid of them necessarily, if they're useful
documentation.

> - is it ok to keep my utility scripts in /usr/share/collectl/util so
> - I don't corrupt /usr/bin with files nobody really ever uses?  The
> - man pages I wrote for them DO include the explicit path so people
> - will know how to find them if they really want to.

That's probably best, because otherwise we *will* need man pages. :)

So I'd just make a release, and then you can make another release if
we come back with a huge set of man page fixes or whatever.

-- 
Tim Retout 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RE: RFS: collectl

2009-12-14 Thread Seger, Mark 
>-Original Message-
>From: Bernd Schubert [mailto:bernd.schub...@fastmail.fm]
>Sent: Monday, December 14, 2009 9:18 AM
>To: Seger, Mark
>Cc: Tim Retout; debian-mentors@lists.debian.org
>Subject: Re: RFS: collectl
>
>Good morning Mark!
>
>On Monday 14 December 2009, Seger, Mark wrote:
>> Figuring it was just easier to do it, I just added man pages for
>client.pl,
>
>Great, thanks. I will check out CVS this evening and then create a new
>package.
>
>>  col2tlviz.pl and reads to the kit. Are the errors about minus signs
>in the
>>  man pages because I reference a switch as text?  If so I agree that
>would
>>  be very ugly and painful to change... I am very close to releasing a
>new
>
>Yes, I think so. Here's a link with the detailed lintian error message:
>
>http://lintian.debian.org/tags/hyphen-used-as-minus-sign.html
>
>I have to clearly admit, that I don't care if it is a hyphen, dash or
>minus,
>for me all three are the same. I even don't know which of those three is
>correct for something link "-s".
>If Tim hadn't told me he wants to have lintian --pedantic errors fixed
>as much
>as possible, I probably never would have cared...
>
>>  version and would like to hear back if there is anything else I can
>do to
>>  make this easier for everyone. -mark
>
>I will give another feedback this evening.
>
I guess I'm a loss of what to do next, if anything.  I haven't been doing 
anything with CVS as collectl is just a couple of scripts.  If it would help I 
could send you a copy of the latest tarball.

So right now I guess the big questions for me are:
- are the man pages ok the way they are without having to worry about 
explicitly quoting everywhere I use a hyphen?  In fact, my keyboard only has a 
single character, do other keyboards actually differentiate?
- I now have 3 more man pages for 3 utilities nobody every would use except me 
and each now references the others.  If this isn't necessary I'd be happy to 
remove them
- is it ok to keep my utility scripts in /usr/share/collectl/util so I don't 
corrupt /usr/bin with files nobody really ever uses?  The man pages I wrote for 
them DO include the explicit path so people will know how to find them if they 
really want to.
- am I missing anything else?

>
>Thanks,
>Bernd
>
>PS: Mark, any chance you could do bottom/interleaved quoting? At least
>as long
>as we CC the mailing list? They are probably going to kill us for "top
>level
>quoting" ;)

Ok  ;-)
-mark


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2009-12-14 Thread Bernd Schubert 
Good morning Mark!

On Monday 14 December 2009, Seger, Mark wrote:
> Figuring it was just easier to do it, I just added man pages for client.pl,

Great, thanks. I will check out CVS this evening and then create a new 
package.

>  col2tlviz.pl and reads to the kit. Are the errors about minus signs in the
>  man pages because I reference a switch as text?  If so I agree that would
>  be very ugly and painful to change... I am very close to releasing a new

Yes, I think so. Here's a link with the detailed lintian error message:

http://lintian.debian.org/tags/hyphen-used-as-minus-sign.html

I have to clearly admit, that I don't care if it is a hyphen, dash or minus, 
for me all three are the same. I even don't know which of those three is 
correct for something link "-s".
If Tim hadn't told me he wants to have lintian --pedantic errors fixed as much 
as possible, I probably never would have cared...

>  version and would like to hear back if there is anything else I can do to
>  make this easier for everyone. -mark

I will give another feedback this evening.


Thanks,
Bernd

PS: Mark, any chance you could do bottom/interleaved quoting? At least as long 
as we CC the mailing list? They are probably going to kill us for "top level 
quoting" ;)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

RE: RFS: collectl

2009-12-14 Thread Seger, Mark 
Figuring it was just easier to do it, I just added man pages for client.pl, 
col2tlviz.pl and reads to the kit.
Are the errors about minus signs in the man pages because I reference a switch 
as text?  If so I agree that would be very ugly and painful to change...
I am very close to releasing a new version and would like to hear back if there 
is anything else I can do to make this easier for everyone.
-mark

>-Original Message-
>From: Bernd Schubert [mailto:bernd.schub...@fastmail.fm]
>Sent: Sunday, December 13, 2009 7:48 PM
>To: Tim Retout
>Cc: debian-mentors@lists.debian.org; Seger, Mark
>Subject: Re: RFS: collectl
>
>Hello Tim,
>
>thanks a lot for your help!
>
>On Tuesday 08 December 2009, Tim Retout wrote:
>> On Mon, Dec 07, 2009 at 12:26:01AM +0100, Bernd Schubert wrote:
>> > Dear mentors,
>> >
>> > I am looking for a sponsor and a little help for my package
>"collectl".
>> >
>> > Firstly I have three package questions.
>> >
>> > 1) The package is based on perl and uses additional modules. As far
>I
>> > know /usr/lib/perl5/collectl would be the optimal path. But upstream
>> > prefers /usr/share/collectl.
>>
>> This depends on whether the perl modules are for use outside of
>collectl
>> or not.  It's probably fine to use /usr/share/collectl, providing the
>> package works.
>
>Great, the patch series has two patches to make it working with
>/usr/share/collectl. I think Mark plans to change future versions to
>find
>collectl libs in that directory by default.
>
>>
>> > 2) Lintian complains
>> >
>> > W: collectl source: quilt-build-dep-but-no-series-file
>> > N:
>> > N: Using quilt requires you to explicitly list all patches you want
>to
>> > N: apply in debian/patches/series. This package build-depends on
>quilt,
>> > but
>> >
>> >
>> > I really do not know what it complains about, as there is non-empty
>> > debian/patches/series file.
>>
>> In the copy on mentors.debian.net, there's no debian/patches/
>directory,
>> so I suspect it's been missed out somehow?
>
>Arg, I think my fault. Accidentally I built with "debuild -i patches",
>which
>also seems to ignore "debian/patches".
>
>>
>> > 3) ITP. An ITP to uload the package was opened by "Simmons,
>Christopher"
>> >  some time ago. But on the one hand
>> > Christopher didn't update the bug report any more and then I created
>an
>> > unofficial collectl package a long time before that. I definitely do
>not
>> > insist to be the package maintainer. I just want to have collectl in
>> > Debian. Christopher, if you are still interested in maintaining
>collectl,
>> > please tell me so. We could either share maintenance or I could hand
>it
>> > over to you.
>>
>> If there's no response within a week of your message, I'll be happy to
>> just go ahead and sponsor your version.
>
>Thanks a lot!
>
>>
>> I'm afraid I'm quite picky, though - I run lintian with '-iI --
>pedantic',
>> so please do the same and fix as many messages as possible.  I'm
>'diocles'
>> on IRC if you have any questions.
>
>I just fixed a couple of --pedantic complaints. Now two issues are left.
>
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:139
>[...]
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:198
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:200
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:202
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:203
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:208
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:228
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:229
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:239
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:252
>I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz
>25
>more occurrences not shown
>
>I already fixed several of those, but I have to admit, that I do not
>agree on
>that solution. There is not a single "minus", but all dashes are
>"hyphens".
>And replacing everything with "\(hy" only reduces readability on editing
>the
>man page.
>
>Second issue is that the helper utility "readS"

RE: RFS: collectl

2009-12-13 Thread Seger, Mark 
This is indeed a timely message as I'm about to upload a new version of 
collectl to sourceforge but am also willing to hold off a tad if any additional 
changes will help.  Sounds like a very brief manpage for readS might help but 
at the same time I had intended it as a minor utility and documented it as such 
on the sourceforge website for collectl.  The same would be true for client.pl 
which is also lacking a manpage.  Further, in my latest kit I chose to make a 
directory called /usr/share/collectl/util and put both client.pl and readS in 
there as I'd rather not pollute /usr/bin with more things than necessary with 
the hope of reducing the chances of another totally unrelated file with the 
same name winding up there, but of course am happy to listen to any other 
suggestions.

Also in this version collectl will indeed look for all ph files in 
/usr/share/collectl if it can't find them in the same directory as collectl 
proper.

I must admit to being confused about the thread about minus signs and hypens in 
the man page as I'm not sure what that is referring to.

-mark

>-Original Message-
>From: Bernd Schubert [mailto:bernd.schub...@fastmail.fm]
>Sent: Sunday, December 13, 2009 7:48 PM
>To: Tim Retout
>Cc: debian-mentors@lists.debian.org; Seger, Mark
>Subject: Re: RFS: collectl
>
>Hello Tim,
>
>thanks a lot for your help!
>
>On Tuesday 08 December 2009, Tim Retout wrote:
>> On Mon, Dec 07, 2009 at 12:26:01AM +0100, Bernd Schubert wrote:
>> > Dear mentors,
>> >
>> > I am looking for a sponsor and a little help for my package
>"collectl".
>> >
>> > Firstly I have three package questions.
>> >
>> > 1) The package is based on perl and uses additional modules. As far
>I
>> > know /usr/lib/perl5/collectl would be the optimal path. But upstream
>> > prefers /usr/share/collectl.
>>
>> This depends on whether the perl modules are for use outside of
>collectl
>> or not.  It's probably fine to use /usr/share/collectl, providing the
>> package works.
>
>Great, the patch series has two patches to make it working with
>/usr/share/collectl. I think Mark plans to change future versions to
>find
>collectl libs in that directory by default.
>
>>
>> > 2) Lintian complains
>> >
>> > W: collectl source: quilt-build-dep-but-no-series-file
>> > N:
>> > N: Using quilt requires you to explicitly list all patches you want
>to
>> > N: apply in debian/patches/series. This package build-depends on
>quilt,
>> > but
>> >
>> >
>> > I really do not know what it complains about, as there is non-empty
>> > debian/patches/series file.
>>
>> In the copy on mentors.debian.net, there's no debian/patches/
>directory,
>> so I suspect it's been missed out somehow?
>
>Arg, I think my fault. Accidentally I built with "debuild -i patches",
>which
>also seems to ignore "debian/patches".
>
>>
>> > 3) ITP. An ITP to uload the package was opened by "Simmons,
>Christopher"
>> >  some time ago. But on the one hand
>> > Christopher didn't update the bug report any more and then I created
>an
>> > unofficial collectl package a long time before that. I definitely do
>not
>> > insist to be the package maintainer. I just want to have collectl in
>> > Debian. Christopher, if you are still interested in maintaining
>collectl,
>> > please tell me so. We could either share maintenance or I could hand
>it
>> > over to you.
>>
>> If there's no response within a week of your message, I'll be happy to
>> just go ahead and sponsor your version.
>
>Thanks a lot!
>
>>
>> I'm afraid I'm quite picky, though - I run lintian with '-iI --
>pedantic',
>> so please do the same and fix as many messages as possible.  I'm
>'diocles'
>> on IRC if you have any questions.
>
>I just fixed a couple of --pedantic complaints. Now two issues are left.
>
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:139
>[...]
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:198
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:200
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:202
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:203
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:208
>I: collectl: hyphen-used-as-minus-sign
>usr/share/man/man1/collectl.1.gz:228
>I: collectl: hyphen-used-as-minus

Re: RFS: collectl

2009-12-13 Thread Russ Allbery 
Bernd Schubert  writes:

> I just fixed a couple of --pedantic complaints. Now two issues are left. 

> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:139
> [...]
> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:198
> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:200
> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:202
> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:203
> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:208
> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:228
> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:229
> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:239
> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:252
> I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz 25 
> more occurrences not shown

> I already fixed several of those, but I have to admit, that I do not
> agree on that solution. There is not a single "minus", but all dashes
> are "hyphens".

Which is wrong in *roff for things like program options.

> And replacing everything with "\(hy" only reduces readability on editing
> the man page.

This is normally the wrong fix.  Usually, the correct fix is to replace -
with \-.  Are you sure that it's really supposed to be a soft Unicode
hyphen instead of an ASCII hyphen?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2009-12-13 Thread Bernd Schubert 
Hello Tim,

thanks a lot for your help!

On Tuesday 08 December 2009, Tim Retout wrote:
> On Mon, Dec 07, 2009 at 12:26:01AM +0100, Bernd Schubert wrote:
> > Dear mentors,
> >
> > I am looking for a sponsor and a little help for my package "collectl".
> >
> > Firstly I have three package questions.
> >
> > 1) The package is based on perl and uses additional modules. As far I
> > know /usr/lib/perl5/collectl would be the optimal path. But upstream
> > prefers /usr/share/collectl.
> 
> This depends on whether the perl modules are for use outside of collectl
> or not.  It's probably fine to use /usr/share/collectl, providing the
> package works.

Great, the patch series has two patches to make it working with 
/usr/share/collectl. I think Mark plans to change future versions to find 
collectl libs in that directory by default.

> 
> > 2) Lintian complains
> >
> > W: collectl source: quilt-build-dep-but-no-series-file
> > N:
> > N: Using quilt requires you to explicitly list all patches you want to
> > N: apply in debian/patches/series. This package build-depends on quilt,
> > but
> >
> >
> > I really do not know what it complains about, as there is non-empty
> > debian/patches/series file.
> 
> In the copy on mentors.debian.net, there's no debian/patches/ directory,
> so I suspect it's been missed out somehow?

Arg, I think my fault. Accidentally I built with "debuild -i patches", which 
also seems to ignore "debian/patches".

> 
> > 3) ITP. An ITP to uload the package was opened by "Simmons, Christopher"
> >  some time ago. But on the one hand
> > Christopher didn't update the bug report any more and then I created an
> > unofficial collectl package a long time before that. I definitely do not
> > insist to be the package maintainer. I just want to have collectl in
> > Debian. Christopher, if you are still interested in maintaining collectl,
> > please tell me so. We could either share maintenance or I could hand it
> > over to you.
> 
> If there's no response within a week of your message, I'll be happy to
> just go ahead and sponsor your version.

Thanks a lot!

> 
> I'm afraid I'm quite picky, though - I run lintian with '-iI --pedantic',
> so please do the same and fix as many messages as possible.  I'm 'diocles'
> on IRC if you have any questions.

I just fixed a couple of --pedantic complaints. Now two issues are left. 

I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:139
[...]
I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:198
I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:200
I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:202
I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:203
I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:208
I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:228
I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:229
I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:239
I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz:252
I: collectl: hyphen-used-as-minus-sign usr/share/man/man1/collectl.1.gz 25 
more occurrences not shown

I already fixed several of those, but I have to admit, that I do not agree on 
that solution. There is not a single "minus", but all dashes are "hyphens". 
And replacing everything with "\(hy" only reduces readability on editing the 
man page.

Second issue is that the helper utility "readS" doesn't have a man page. Mark, 
any chance you could provide a short description what readS is actually for? 
By reading the perl code for less than one minute I see it does lots of text 
manipulation, but don't understand the main intent of the tool yet.


> 
> I may also ask you to maintain this as part of the pkg-perl apps
> repository, but I haven't decided yet. :)
> 

Ah, nice. I didn't know this group even exists. Although collectl is a bit 
different than the other packages in that group, I think. E.g. it doesn't use 
perl to install itself. Hmm, maybe I take on the of the other packages there 
to improve that...

I just upload a new package version: 

http://mentors.debian.net/debian/pool/main/c/collectl/collectl_3.3.6-4.dsc


Time to go to bed now...


Cheers,
Bernd


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: collectl

2009-12-08 Thread Tim Retout 
On Mon, Dec 07, 2009 at 12:26:01AM +0100, Bernd Schubert wrote:
> Dear mentors,
> 
> I am looking for a sponsor and a little help for my package "collectl".
> 
> Firstly I have three package questions. 
> 
> 1) The package is based on perl and uses additional modules. As far I know 
> /usr/lib/perl5/collectl would be the optimal path. But upstream prefers
> /usr/share/collectl. 

This depends on whether the perl modules are for use outside of collectl
or not.  It's probably fine to use /usr/share/collectl, providing the
package works.

> 2) Lintian complains
> 
> W: collectl source: quilt-build-dep-but-no-series-file
> N: 
> N: Using quilt requires you to explicitly list all patches you want to
> N: apply in debian/patches/series. This package build-depends on quilt, but
> 
> 
> I really do not know what it complains about, as there is non-empty 
> debian/patches/series file.

In the copy on mentors.debian.net, there's no debian/patches/ directory,
so I suspect it's been missed out somehow?

> 3) ITP. An ITP to uload the package was opened by "Simmons, Christopher" 
>  some time ago. But on the one hand Christopher 
> didn't update the bug report any more and then I created an unofficial 
> collectl package a long time before that. I definitely do not insist to be 
> the 
> package maintainer. I just want to have collectl in Debian. Christopher, if 
> you are still interested in maintaining collectl, please tell me so. We could 
> either share maintenance or I could hand it over to you.

If there's no response within a week of your message, I'll be happy to
just go ahead and sponsor your version.

I'm afraid I'm quite picky, though - I run lintian with '-iI --pedantic',
so please do the same and fix as many messages as possible.  I'm 'diocles'
on IRC if you have any questions.

I may also ask you to maintain this as part of the pkg-perl apps
repository, but I haven't decided yet. :)

-- 
Tim Retout 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org