Re: Convenience copies in upstream code: dependencies, removal, copyright, and other issues

[Don Armstrong]

On Tue, 20 Oct 2009, Felipe Sateler wrote:
> On Tue, 2009-10-20 at 12:05 -0700, Don Armstrong wrote:
> > This is because we don't only distribute the binaries; we also
> > distribute the source.
> 
> But the upstream source already has them (in the source files
> themselves or other files).

Sure, but it's often spread through hundreds of files.

> The copyright file is for installation in the binary packages (as
> per my reading of policy 12.5).

That's true, but debian/copyright documents the licensing of the
source package, not necessarily the resultant binary package. [If for
no other reason than it's relatively easy to do the former, and
incredibly difficult to do the latter.]

> I don't see how including that info saves work for them since they
> check it anyways.

It's easier to look at a single file which lists all of the licenses
in a source package than trolling through hundreds of files, trying to
make sure you've got them all.

While I certainly can't speak for the ftpmasters themselves, if I were
one, I'd personally put off processing packages which obviously
misssed licenses. In those cases, I wouldn't be able to trust the
maintainer to have done due dilligence at all, and would have to spend
more time doing what should have been the maintainer's job in the
first place.


Don Armstrong

-- 
Cheop's Law: Nothing ever gets built on schedule or within budget.
 -- Robert Heinlein _Time Enough For Love_ p242

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

RFS: lesstif2 AND Questions about collab-maint

[Paul Gevers]

Hi mentors and mentees,

[Sorry for the long mail, there are several issues/questions.]

I am looking for a thourough check of my packaging and preferably a
sponsor for the new version 1:0.95.2-1 of my package "lesstif2" [0].
This new upstream version is only the incorporation of a lot of patches
already incorporated in the current version of lesstif2 in Debian.

Lesstif2 has been moved to collab-maint [1], because the original
maintainer, Sam Hocevar, agreed that I could co-maintain lesstif2 with
him. However, Sam Hocevar, hasn't responded to my last e-mails about
checking the packaging and uploading. He previously suggested mailing
the other collab-maint people in parallel, so that they could sponsor. I
tried the collab-maint-de...@lists.alioth.debian.org email address, but
that doesn't exist anymore. Now I am looking for the best way to ask for
a check of the packaging. Would anybody know the way to reach the
collab-maint people? Or is this list the most appropriate place anyway?
In the latter case, do I understand correctly that mentors still want an
upload to mentors.d.n? Just in case for the latter, I build the package
and uploaded to m.d.n [2]. I would appreciate comments (changelog at the
bottom of this mail [3]).

lesstif2 builds these binary packages:
lesstif-bin - user binaries for LessTif
lesstif-doc - documentation for LessTif
lesstif2   - OSF/Motif 2.1 implementation released under LGPL
lesstif2-dbg - lesstif2 debugging files
lesstif2-dev - development library and header files for LessTif 2.1

The upload would fix this bug: 409093

The package is NOT completely lintian free (39 times the next warning):
"""
W: lesstif-doc: manpage-has-errors-from-man
usr/share/man/man3/.3.gz  around line : table wider than line
width
"""
To solve this I need to re-arrange a lot of tables. Does anybody know a
nice way to order them? Currently it is like:
   Name  Class Type
Default   Access


   XtNx  XtCPosition   Position
NULL  CSG
My suggestion would be something like (is this readable?):
   Name  Class Type
   Default
   Access
   -
   XtNx  XtCPosition   Position
   NULL
   CSG

With kind regards
Paul

[0] LessTif, made by the Hungry Programmers, is a free (LGPL-ed) version
of OSF/Motif; it aims ultimately at binary compatibility with Motif 2.1.

[1] http://svn.debian.org/viewsvn/collab-maint/deb-maint/lesstif2/

[2] The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/lesstif2
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/lesstif2/lesstif2_0.95.2-1.dsc

[3]
lesstif2 (1:0.95.2-1) unstable; urgency=low

  [Sam Hocevar]
  * Acknowledging past NMUs. Thanks to Aaron M. Ucko and Paul Gevers, who
now co-maintains this package (Closes: #396199, #479779, #503361,
#314440,
Closes: #43640, #87745, #356017, #496081, #330057, #439186).
  * debian/control:
+ Add Paul Gevers to the uploaders list.
+ Update Vcs fields.

  [Paul Gevers]
  * New upstream release (dropping deprecated patches)
- 020_bad_integer_cast.diff (solved upstream)
- 020_unsigned_int.diff (included upstream)
- 021_xim_chained_list_crash.diff (included upstream)
- 031_fix_inverted_scrollwheel.diff (included upstream)
- 031_shutup_xtungrabbutton.diff (included upstream)
- 040_fedora_accelkeys.diff (included upstream)
- 040_fedora_c++fix.diff (included upstream)
- 040_fedora_text.diff (included upstream)
- 050_cvs_invalid_pointer.diff (was from upstream)
- 050_cvs_1773603_invalid_pointer_TextOut.c.diff (was from upstream)
- 050_cvs_1773603_invalid_pointer_List.c.diff (was from upstream)
- 050_cvs_1773603_invalid_pointer_Label.c.diff (was from upstream)
- 050_cvs_1773603_invalid_pointer_LabelG.c.diff (was from upstream)
- 050_cvs_class_initialize_DialogS.c.diff (was from upstream)
- 050_cvs_attachbottom_Form.c.diff (was from upstream)
- 060_update_manpages (included upstream)
- 071_fix_crash_on_ESC_Traversal.c (included upstream)
Remaining patches (updated descriptions, conform current DEP3
proposal):
- 000_bootstrap_script.diff (updated, in sync with upstream CVSMake)
- 000_libtool_linking.diff (leave as is, debian specific, path)
- 010_rebootstrap (updated, see also 000_bootstrap_script.diff)
- 020_missing_xm_h.diff (not included upstream yet)
- 020_render_table_crash.diff (in u

Re: RFS: ampache (updated package)

[Manoj Srivastava]

On Tue, Oct 20 2009, Jan Hauke Rahm wrote:

> On Tue, Oct 20, 2009 at 02:28:09PM -0500, Manoj Srivastava wrote:
>> On Tue, Oct 20 2009, George Danchev wrote:
>> 
>> >> On Tue, Oct 20 2009, Paul Wise wrote:
>> >> > On Tue, Oct 20, 2009 at 3:56 PM, Jan Hauke Rahm  wrote:
>> >> >> In future check your packages with 'lintian -IE --pedantic *.changes' 
>> >> >> to
>> >> >> catch minor issues. But the package looks good! :)
>> >> >
>> >> > Personally, I use this as it catches more things and gives more detail:
>> >> >
>> >> > lintian --info --display-info --display-experimental --pedantic
>> >> > --show-overrides --checksums --color
>> >> 
>> >> I find that experimental and pedantic add far too much
>> >>  irrelevant chatter, and that it tends to mask the problems one should
>> >>  actually fix.
>> >
>> >Then split'em up and use on demand. For instance, use one shell
>> > alias for 'must fix these', when done use another one for 'pedantic'
>> > mode, if you like to, which should be enough to demask lintian
>> > reports.
>> >
>> >I think that experimenting with experimental/pedantic and
>> > eventually report results to BTS could help lintian developers to
>> > evaluate some information in advance about future infiltration and
>> > impact of these experimental checks, how useful, robust, or eventually
>> > boring they are, so they tweak the development heading according to
>> > the 'wind conditions'.
>> 
>> If you want to help improve lintian, sure. If you have the
>>  experience and the patience, that is great. But suggesting it to a
>>  bunch of novices trying to learn how to create packages might notbe the
>>  best advice -- the experimental stuff is not something that is
>>  necessarily things that ought to be fixed in the first place, and the
>>  -I stuff is debatable.  If you are learning how to package stuff,
>>  concentrate on things you _do_ need to fix.  Move on to helping fix
>>  lintian once you are comfortable with packaging, and have developed
>>  some judgment about where lintian ought to be heading.
>
> As much as In understand your issue here, note that I suggested the
> experimental and pedantic test for a last check. I expect that a package
> is working (i.e. no FTBFS, installable, removable etc.) even before
> lintian is used at all. As a last stepbefore uploading a package I find
> -I -E --pedantic very appropriate.

The fallacy here is that the experimental stuff is clutter, it
 is not really a check of your package -- it is a check of lintian, and
 unless you give feedback to lintian, you might as well not obscure the
 rest of the information from lintian.

Secondly, have you read the description of pedantic? Pedantic
 tags are Lintian at its most pickiest and include checks for particular
 Debian packaging styles, checks that are very frequently wrong, and
 checks that many people disagree with.  Expect false positives and
 Lintian tags that you don't consider useful if you use this option.


> You catch common typos in descriptions, catch some "should" guidelines
> from policy etc. It's not like you have to fix it but if you can, all
> the better...

Hmm. Information that is:

Frequently wrong.

Has false Positives.

Matter of taste.

If you are learning how to package stuff for Debian, is this
 really a good use of your time?  You can't yet tell that what lintian
 tells you is right or wrong, and you can't yet tell if the check is
 merely a matter of taste. A foolish consistency is the hobgoblin etc
 etc. 

manoj
-- 
My brother sent me a postcard the other day with this big satellite
photo of the entire earth on it. On the back it said: "Wish you were
here". -- Steven Wright
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: RFS: ampache (updated package)

[Manoj Srivastava]

On Tue, Oct 20 2009, Raphael Geissert wrote:

> Hi Manoj,
>
> Manoj Srivastava wrote:
> [...]
>> 
>> I find that experimental and pedantic add far too much
>>  irrelevant chatter, and that it tends to mask the problems one should
>>  actually fix.
>> 
>
> Could you please elaborate a bit more? I'd like to know how I can improve
> lintian so that it is more useful for others.

,[  Manual page lintian(1)  ]
|  --pedantic
| Display pedantic ("P:") tags as well.  They are normally
| suppressed.
| 
| Pedantic tags are Lintian at its most pickiest and include
| checks for particular Debian packaging styles, checks that are
| very frequently wrong, and checks that many people disagree
| with.  Expect false positives and Lintian tags that you don't
| consider useful if you use this option.  Adding overrides for
| pedantic tags is probably not worth the effort.
`

Pretty much covers it, neh?

Also:

,[ http://lintian.debian.org/manual/ch2.html#s2.3 ]
| Experimental:
|   This means that the code that generates this message is not as well
|   tested as the rest of Lintian, and might still give surprising
|   results. Feel free to ignore Experimental messages that do not seem to
|   make sense, though of course bug reports are always welcomed.
`

Now, people experienced in packaging stuff for Debian ought to
 be looking at pedantic and experimental tags and giving feedback to
 Lintian, to improve it (I certainly do). But I only look at
 experimental and pedantic tags when I want to see f I want to give
 feedback to Lintian, not as a package check. As a package check it is
 very inefficient, and definitely not what I would recommend to a
 novice.

There is a time and a place where these lintian options are
 useful. They certainly have a place, and are recommended for
 experienced developers, and critical for helping to improve lintian.
 But one needs to know when to use them, and when not to bother. 

manoj
-- 
"Linux: the operating system with a CLUE... Command Line User
Environment". (seen in a posting in comp.software.testing)
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: RFS: texi2html (updated package) fix bug: 534127

[Francesco Cecconi]

Hi Hauke,

On Sunday 18 October 2009 13:33:56 Jan Hauke Rahm wrote:
> Hi Francesco,
>
> On Wed, Oct 14, 2009 at 01:26:39PM +0200, Francesco Cecconi wrote:
> > I am looking for a sponsor for the new version 1.82-1
> > of my package "texi2html".
> >
> > It builds these binary packages:
> > texi2html  - Convert Texinfo files to HTML
>
> Your package looks pretty good!
>
> > The package appears to be lintian clean.
> >
> > The upload would fix these bugs: 534127
>
> Almost lintian clean (remember to call lintian with -I to see additional
> issues). Please add a description to your patch header.
done
>
> Also, I'm wondering why you didn't fix #451654 which lintian also
> complains about. It's not too hard to write a doc-base control file, is
> it? :)
done 
>
> From your debian/rules, just out of curiosity:
> * Why did you explicitly add "dh_installdocs debian/README.source"? I
>   think debhelper7 can handle it by itself and even if not, adding it to
>   debian/docs looks more straight forward to me. Any reason?
done, debhelper7 handle it by itself :)

> * You have quite a few lines for the CFLAGS but you're building an arch:
>   all package. Is there something that is compiled or is that bogus? :)
done, i have updated the rules
>
> One last thing: why didn't you update to the latest upstream version
> earlier? There is even a bug report about it, so I assume you missed the
> new version somehow?
yes Hauke, i missed the new upstream version :)
>
> I'd be glad to upload your package after clearing these few points.
many thanks for your work
>
> Hauke
Cheers,
Francesco


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

Re: RFS: texi2html (updated package) fix bug: 534127

[Jan Hauke Rahm]

Hi Francesco,

On Wed, Oct 21, 2009 at 11:26:53AM +0200, Francesco Cecconi wrote:
> > * You have quite a few lines for the CFLAGS but you're building an arch:
> >   all package. Is there something that is compiled or is that bogus? :)
> done, i have updated the rules

To be clear: you didn't have to, I just wanted to make sure you know
what you're doing. :)

> > One last thing: why didn't you update to the latest upstream version
> > earlier? There is even a bug report about it, so I assume you missed the
> > new version somehow?
> yes Hauke, i missed the new upstream version :)

Happens.

Uploaded.

For future releases: use changelog to document what you're doing (and
possibly why) instead of what files you're acting on. I.e.

  * Switched to debhelper 7

instead of

  * [debian/control]: update debhelper to version 7
  * [debian/compat]: updated to level 7
  * [debian/rules]: Updated

It's pretty obvious that you updated debian/compat and debian/control
but not what you actually changed in the build process. If you want to
be more verbose, elaborate what you really did.

  * Switched to debhelper 7
+ debian/control: updated dependency
+ debian/rules: removed unnecessary dh_* calls, changed dh_clean -k
  to dh_prep

Or similar... It is just a matter of taste after all, so just a
suggestion. :)

Hauke


signature.asc
Description: Digital signature

Re: RFS: ampache (updated package)

[Jan Hauke Rahm]

Hi Manoj,

I'm not going to argue with you about this.

On Wed, Oct 21, 2009 at 04:12:21AM -0500, Manoj Srivastava wrote:
> There is a time and a place where these lintian options are
>  useful. They certainly have a place, and are recommended for
>  experienced developers, and critical for helping to improve lintian.
>  But one needs to know when to use them, and when not to bother. 

I just think that this is the wrong perspective. lintian usually has
good explanations and I find it for novices particularly helpfull to
read those. They rediect to Policy, DevRef etc.

And the most important part is: not a single lintian complaint has to be
fixed because lintian says so. It's just a tool. Bugs have to be fixed
and if lintian finds those -- good. And if a new maintainer doesn't
understand what a lintian (pedantic, info, warning or whatever severity)
issue is about, then it's time to ask. That's what -mentors is about; or
at least I always thought so.

Hauke


signature.asc
Description: Digital signature

Re: RFS: texi2html (updated package) fix bug: 534127

[Francesco Cecconi]

Hi Hauke,

On Wednesday 21 October 2009 12:09:06 Jan Hauke Rahm wrote:
> Hi Francesco,
>
> On Wed, Oct 21, 2009 at 11:26:53AM +0200, Francesco Cecconi wrote:
> > > * You have quite a few lines for the CFLAGS but you're building an
> > > arch: all package. Is there something that is compiled or is that
> > > bogus? :)
> >
> > done, i have updated the rules
>
> To be clear: you didn't have to, I just wanted to make sure you know
> what you're doing. :)
sure :)
>
> > > One last thing: why didn't you update to the latest upstream version
> > > earlier? There is even a bug report about it, so I assume you missed
> > > the new version somehow?
> >
> > yes Hauke, i missed the new upstream version :)
>
> Happens.
>
> Uploaded.
many thanks Hauke
>
> For future releases: use changelog to document what you're doing (and
> possibly why) instead of what files you're acting on. I.e.
>
>   * Switched to debhelper 7
>
> instead of
>
>   * [debian/control]: update debhelper to version 7
>   * [debian/compat]: updated to level 7
>   * [debian/rules]: Updated
>
> It's pretty obvious that you updated debian/compat and debian/control
> but not what you actually changed in the build process. If you want to
> be more verbose, elaborate what you really did.
>
>   * Switched to debhelper 7
> + debian/control: updated dependency
> + debian/rules: removed unnecessary dh_* calls, changed dh_clean -k
>   to dh_prep
>
> Or similar... It is just a matter of taste after all, so just a
> suggestion. :)
>
> Hauke
Francesco


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

Re: Re: RFS: stx-btree

[Ury Stankevich]

Thanks for your help, i have fixed flaws you notice.


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

Lintian pickiness and packaging improvements (was: RFS: ampache (updated package))

[Ben Finney]

Jan Hauke Rahm  writes:

> Hi Manoj,
>
> I'm not going to argue with you about this.
>
> On Wed, Oct 21, 2009 at 04:12:21AM -0500, Manoj Srivastava wrote:
> > There is a time and a place where these lintian options are
> >  useful. They certainly have a place, and are recommended for
> >  experienced developers, and critical for helping to improve
> >  lintian. But one needs to know when to use them, and when not to
> >  bother.

I think this approach is right for Lintian's experimental checks. They
should be enabled only by those who want to improve Lintian by finding
faults in the checks.

I don't think it's right for the pedantic checks that are *not*
experimental. If those are never used except by people who want to
improve Lintian, then there seems to be little point. So applying this
attitude to the Lintian pedantic checks seems to be an argument for not
having them in Lintian at all.

> I just think that this is the wrong perspective. lintian usually has
> good explanations and I find it for novices particularly helpfull to
> read those. They rediect to Policy, DevRef etc.

Yes. Those checks (that are not experimental) that cause a tag on one's
package should cause one to seriously consider whether, and have a
convincing answer for why, this package might be an exception to the
check.

> And the most important part is: not a single lintian complaint has to
> be fixed because lintian says so. It's just a tool.

Please join me in public embarrassment of those who write changelog
entries saying “make Lintian happy”, etc.

Lintian is not a deity to be appeased; it's a tool reporting that the
package might need fixing for explicit *reasons*, formulated by fellow
developers. The changelog entry for the fix should not even mention
Lintian and should speak only to the reason given for the check.

-- 
 \  “What we usually pray to God is not that His will be done, but |
  `\   that He approve ours.” —Helga Bergold Gross |
_o__)  |
Ben Finney


pgp6Tj7NMZe46.pgp
Description: PGP signature

Re: Lintian pickiness and packaging improvements (was: RFS: ampache (updated package))

[Paul Wise]

On Wed, Oct 21, 2009 at 7:48 PM, Ben Finney  wrote:

> Please join me in public embarrassment of those who write changelog
> entries saying “make Lintian happy”, etc.
>
> Lintian is not a deity to be appeased; it's a tool reporting that the
> package might need fixing for explicit *reasons*, formulated by fellow
> developers. The changelog entry for the fix should not even mention
> Lintian and should speak only to the reason given for the check.

Sounds like a target for a new lintian check ;)

We are getting off-topic now, my apologies for starting that with my
initial mail.

-- 
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: Lintian pickiness and packaging improvements (was: RFS: ampache (updated package))

[Charlie Smotherman]

On Wed, 2009-10-21 at 19:53 +0800, Paul Wise wrote:
> On Wed, Oct 21, 2009 at 7:48 PM, Ben Finney  
> wrote:
> 
> > Please join me in public embarrassment of those who write changelog
> > entries saying “make Lintian happy”, etc.
> >
> > Lintian is not a deity to be appeased; it's a tool reporting that the
> > package might need fixing for explicit *reasons*, formulated by fellow
> > developers. The changelog entry for the fix should not even mention
> > Lintian and should speak only to the reason given for the check.
> 
> Sounds like a target for a new lintian check ;)
> 
> We are getting off-topic now, my apologies for starting that with my
> initial mail.
> 

If the discussion of lintian is finished would someone please sponsor
ampache-themes (Hauke)

http://mentors.debian.net/debian/pool/main/a/ampache-themes/ampache-themes_3.4.4-1.dsc
 

Thank you 
Charlie Smotherman


signature.asc
Description: This is a digitally signed message part

RFS: qbzr

[stefano karapetsas]

Dear mentors,

I am looking for a sponsor for my package "qbzr". The package is already
in Ubuntu and I got inspiration from this package, uploaded by QBzr
developers.

* Package name: qbzr
  Version : 0.15-1
  Upstream Author : Lukáš Lalinský 
* URL : http://bazaar-vcs.org/QBzr
* License : GNU GPL v2 
  Section : devel

It builds these binary packages:
qbzr   - Qt frontend for Bazaar commands

The package appears to be lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/q/qbzr
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/q/qbzr/qbzr_0.15-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Stefano Karapetsas


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

Re: Lintian pickiness and packaging improvements

[Manoj Srivastava]

On Wed, Oct 21 2009, Ben Finney wrote:

> Jan Hauke Rahm  writes:

>> On Wed, Oct 21, 2009 at 04:12:21AM -0500, Manoj Srivastava wrote:
>> > There is a time and a place where these lintian options are
>> >  useful. They certainly have a place, and are recommended for
>> >  experienced developers, and critical for helping to improve
>> >  lintian. But one needs to know when to use them, and when not to
>> >  bother.

> I think this approach is right for Lintian's experimental checks. They
> should be enabled only by those who want to improve Lintian by finding
> faults in the checks.
>
> I don't think it's right for the pedantic checks that are *not*
> experimental. If those are never used except by people who want to
> improve Lintian, then there seems to be little point.

It is not I who made the  comments about the quality of pedantic
 checks: Lintian authors have said:

Pedantic tags are Lintian at its most pickiest and include
checks for particular Debian packaging styles, checks that are
very frequently wrong, and checks that many people disagree
with.  Expect false positives and Lintian tags that you don't
consider useful if you use this option.  Adding overrides for
pedantic tags is probably not worth the effort.

Th other point is: this is a forum for people new to Debian
 packaging. There such things as advanced topics; things not to do until
 you have some experience and can distinguish between things that are
 lacunae and things that are stylistic differences.With experience, one
 may tell the difference between false positives, and checks which are,
 in your opinion, just wrong and can be discarded.

> So applying this attitude to the Lintian pedantic checks seems to be
> an argument for not having them in Lintian at all.

Err, no. Experienced developers might gain some benefit from
 this class of reports. They are in a separate class for a reason. I do
 not think inexperienced people need look at these, there is already
 information overload for novices, let them first gain the experience,
 and then go back an look at the pedantic tags and see which ones they
 need to change.

manoj
-- 
"Well I don't see why I have to make one man miserable when I can make
so many men happy." -- Ellyn Mustard, about marriage
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: request for review: lbzip2-0.16rc1-1

[Paul Wise]

There is one lintian warning:

I: lbzip2 source: quilt-patch-missing-description makefile

The package fails to unapply the debian patches in the clean rule. As
a result, some files get embedded in the diff.gz when built several
times in a row:

lbzip2-0.16rc1/.pc/applied-patches
lbzip2-0.16rc1/.pc/.version
lbzip2-0.16rc1/.pc/man-inst-paths/lbzip2.1
lbzip2-0.16rc1/.pc/makefile/Makefile

Please note that you need to remove the patches after running make
clean, since you patch the Makefile.

I get some GCC warnings when I add -Wall to the CFLAGS, like most
Debian source packages have.

I personally think you could merge the Makefile patch upstream. I've
attached what I think the Makefile and rules file would look like if
you do that. The changes I've made make it feel a bit more like an
automake project. If you were to throw autotools into the mix, you
could get rid of the first hunk of the manual page patch too. For the
second hunk, manual pages can contain a BUGS section. I understand
completely if you do not want to adopt my changes.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


Makefile
Description: Binary data


rules
Description: Binary data

Re: Lintian pickiness and packaging improvements (was: RFS: ampache (updated package))

[Jan Hauke Rahm]

On Wed, Oct 21, 2009 at 08:14:54AM -0500, Charlie Smotherman wrote:
> On Wed, 2009-10-21 at 19:53 +0800, Paul Wise wrote:
> > On Wed, Oct 21, 2009 at 7:48 PM, Ben Finney  
> > wrote:
> > 
> > > Please join me in public embarrassment of those who write changelog
> > > entries saying “make Lintian happy”, etc.
> > >
> > > Lintian is not a deity to be appeased; it's a tool reporting that the
> > > package might need fixing for explicit *reasons*, formulated by fellow
> > > developers. The changelog entry for the fix should not even mention
> > > Lintian and should speak only to the reason given for the check.
> > 
> > Sounds like a target for a new lintian check ;)
> > 
> > We are getting off-topic now, my apologies for starting that with my
> > initial mail.
> > 
> 
> If the discussion of lintian is finished would someone please sponsor
> ampache-themes (Hauke)

I hope you meant that *way* less sarcastic then it sounded to me...

> http://mentors.debian.net/debian/pool/main/a/ampache-themes/ampache-themes_3.4.4-1.dsc
>  
> 
> Thank you 
> Charlie Smotherman

Done. You're welcome.
Hauke


signature.asc
Description: Digital signature

Re: Lintian pickiness and packaging improvements (was: RFS: ampache (updated package))

[Charlie Smotherman]

On Wed, 2009-10-21 at 19:27 +0200, Jan Hauke Rahm wrote:
> On Wed, Oct 21, 2009 at 08:14:54AM -0500, Charlie Smotherman wrote:
> > On Wed, 2009-10-21 at 19:53 +0800, Paul Wise wrote:
> > > On Wed, Oct 21, 2009 at 7:48 PM, Ben Finney  
> > > wrote:
> > > 
> > > > Please join me in public embarrassment of those who write changelog
> > > > entries saying “make Lintian happy”, etc.
> > > >
> > > > Lintian is not a deity to be appeased; it's a tool reporting that the
> > > > package might need fixing for explicit *reasons*, formulated by fellow
> > > > developers. The changelog entry for the fix should not even mention
> > > > Lintian and should speak only to the reason given for the check.
> > > 
> > > Sounds like a target for a new lintian check ;)
> > > 
> > > We are getting off-topic now, my apologies for starting that with my
> > > initial mail.
> > > 
> > 
> > If the discussion of lintian is finished would someone please sponsor
> > ampache-themes (Hauke)
> 
> I hope you meant that *way* less sarcastic then it sounded to me...
> 
No sarcasm or disrespect intended, I actually thought I was being
respectful, and polite waiting for the discussion of lintian (which I
found very helpful) to be over before I requested sponsoring of
ampache-themes.  My apologies if you were offended.   
 
> > http://mentors.debian.net/debian/pool/main/a/ampache-themes/ampache-themes_3.4.4-1.dsc
> >  

Best regards
Charlie Smotherman


signature.asc
Description: This is a digitally signed message part

Re: Lintian pickiness and packaging improvements (was: RFS: ampache (updated package))

[Jan Hauke Rahm]

On Wed, Oct 21, 2009 at 01:08:43PM -0500, Charlie Smotherman wrote:
> On Wed, 2009-10-21 at 19:27 +0200, Jan Hauke Rahm wrote:
> > On Wed, Oct 21, 2009 at 08:14:54AM -0500, Charlie Smotherman wrote:
> > > On Wed, 2009-10-21 at 19:53 +0800, Paul Wise wrote:
> > > > On Wed, Oct 21, 2009 at 7:48 PM, Ben Finney 
> > > >  wrote:
> > > > 
> > > > > Please join me in public embarrassment of those who write changelog
> > > > > entries saying “make Lintian happy”, etc.
> > > > >
> > > > > Lintian is not a deity to be appeased; it's a tool reporting that the
> > > > > package might need fixing for explicit *reasons*, formulated by fellow
> > > > > developers. The changelog entry for the fix should not even mention
> > > > > Lintian and should speak only to the reason given for the check.
> > > > 
> > > > Sounds like a target for a new lintian check ;)
> > > > 
> > > > We are getting off-topic now, my apologies for starting that with my
> > > > initial mail.
> > > > 
> > > 
> > > If the discussion of lintian is finished would someone please sponsor
> > > ampache-themes (Hauke)
> > 
> > I hope you meant that *way* less sarcastic then it sounded to me...
> > 
> No sarcasm or disrespect intended, I actually thought I was being
> respectful, and polite waiting for the discussion of lintian (which I
> found very helpful) to be over before I requested sponsoring of
> ampache-themes.  My apologies if you were offended.   

Blame my not being an english native speaker. :)

Hauke


signature.asc
Description: Digital signature

RFS: libnet-tftpd-perl

[Benoit Mortier]

Dear mentors,

I am looking for a sponsor for my package "libnet-tftpd-perl".

* Package name: libnet-tftpd-perl
  Version : 0.04-1
  Upstream Author : Luigino Masarati 
* URL : http://search.cpan.org/dist/Net-TFTPd/
* License : GPL
  Section : perl

It builds these binary packages:
libnet-tftpd-perl - Perl extension for Trivial File Transfer Protocol 
Server

The package appears to be lintian clean.

The upload would fix these bugs: 551817

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libnet-tftpd-perl
- Source repository: deb-src http://mentors.debian.net/debian unstable 
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/l/libnet-tftpd-perl/libnet-tftpd-perl_0.04-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Benoit Mortier
-- 
Benoit Mortier
CEO 
OpenSides "logiciels libres pour entreprises" : http://www.opensides.be/
Contributor to Gosa Project : http://gosa-project.org/


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

RFS: libpam-storepw

[Benoit Mortier]

Dear mentors,

I am looking for a sponsor for my package "libpam-storepw".

* Package name: libpam-storepw
  Version : 0.5-1
  Upstream Author : Florian Lohoff 
* URL : none
* License : GPL
  Section : admin

It builds these binary packages:
libpam-storepw - PAM module allowing to store password for later usage

The package appears to be lintian clean.

The upload would fix these bugs: 532677

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libpam-storepw
- Source repository: deb-src http://mentors.debian.net/debian unstable 
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/l/libpam-storepw/libpam-storepw_0.5-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Benoit Mortier
-- 
Benoit Mortier
CEO 
OpenSides "logiciels libres pour entreprises" : http://www.opensides.be/
Contributor to Gosa Project : http://gosa-project.org/


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

Re: RFS: stx-btree

[George Danchev]

> Thanks for your help, i have fixed flaws you notice.
> 

Hi,

* your binary-indep should not depend on targets that try compile the test-
suites (speedtest, wxbtreedemo, testsuite), but should only install 
architecture independent parts of the source package into the corresponding 
-dev (headers files containing templates) and -doc (doxygen files) binary 
packages.

* your binary-arch can compile the test-suites and eventually clean the 
resulting object files right after that, in order to verify it succeeds on 
various architectures, and should not install anything into binary package 
directories since your source package does not have architecture dependent 
binary packages (arch: any or arch: ). However, since your source 
package only has two architecture independent binary packages (arch: all) and 
currently Debian autobuilders do not build these parts (but only architecture 
dependent ones via dpkg-buildpackage -B, actually your source package won't 
even reach the autobuilders) these test-suites will only be built on the 
architecture uploading DD happens to use. That will hopefully change in the 
near future when autobuilders start to build every part of the source package 
themselves.

As a side note: to be honest it doesn't make any big difference whether you 
compile the test-suite within binary-arch or binary-indep, since you throw out 
the resulting object files anyway once completed, but I guess the style is best 
to be kept sane ;-) Also, at some later point you might decide to split a 
separate wxbtreedemo binary package (arch:any) so it must be handled by 
binary-arch anyway (debian policy 4.7).

* there are some more build-dependencies (wx, cppunit) you could add related 
to test-suites, though configure script handles these gracefully if they are 
not present, but you want to run the test-suite after all ;-).

* long description could be improved based on the top-level README file (add 
some salt, like what improvements these containers bring over STL ones)

* debian/copyright is incomplete - there are GPL-2'ed source files in 
wxbtreedemo directory (licensecheck -r . from devscripts package might be of 
service). Also, /usr/share/common-licenses/LGPL is a symlink, you want to use 
LGPL-2.1 in your copyright file, same for GPL-2.

* add README.Debian explaining there is no corresponding library package 
containing object files, but only a development one; also point out that test-
suites could serve as examples and could be found in the source package 
itself.

-- 
pub 4096R/0E4BD0AB 


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

RFS: boats (updated package)

[Thibaut GRIDEL]

Dear mentors,

I am looking for a sponsor for the new version 200910-1
of my package "boats".

It builds these binary packages:
boats  - a race scenario drawing tool

The package is lintian clean and builds with pbuilder.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/b/boats
- Source repository: deb-src http://mentors.debian.net/debian unstable
  main contrib non-free
- dget
  http://mentors.debian.net/debian/pool/main/b/boats/boats_200910-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Thibaut GRIDEL



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

Re: Lintian pickiness and packaging improvements

[Ben Finney]

Charlie Smotherman  writes:

> No sarcasm or disrespect intended, I actually thought I was being
> respectful, and polite waiting for the discussion of lintian (which I
> found very helpful) to be over before I requested sponsoring of
> ampache-themes.

There's no need to wait. The reason I changed the subject line was to
allow discussion of the original thread to continue without confusion.
Topic drift happens, and we need to deal with it rather than allowing it
to impede discussion.

Sadly, you then replied in this changed-topic thread, wanting to discuss
the original topic; you would have done better to reply to a
pre-topic-change message, making it clear what your message was about by
its subject field.

Perceiving messages in a discussion as a serial queue is less useful,
and less natural, than thinking of them as a branching tree.

> My apologies if you were offended.

No offense was taken that I'm aware of.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “Uh, I think so, |
  `\ Brain, but we'll never get a monkey to use dental floss.” |
_o__)   —_Pinky and The Brain_ |
Ben Finney


pgpCbnW2MkMY5.pgp
Description: PGP signature

Re: Lintian pickiness and packaging improvements

[Ben Finney]

Manoj Srivastava  writes:

> Err, no. Experienced developers might gain some benefit from
>  [pedantic] reports. They are in a separate class for a reason. I do
>  not think inexperienced people need look at these, there is already
>  information overload for novices, let them first gain the experience,
>  and then go back an look at the pedantic tags and see which ones they
>  need to change.

Fair enough. I can see merit in that position, thanks for clarifying it.

-- 
 \ “Injustice is relatively easy to bear; what stings is justice.” |
  `\ —Henry L. Mencken |
_o__)  |
Ben Finney


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

Library builds with pkg-config

[Mats Erik Andersson]

Hello,

I am trying to find the correct way of installing a pkg-config
specification, the like of 

 /usr/lib/pkgconfig/dummy.ac

for the developmental package of a library. Would

  1)   # debian/control
   Depends: pkgconfig

  2)   # debian/rules
   dh_install debian/dummy.ac usr/lib/pkgconfig/

together suffice for this task? I seem not able to locate
a tailored debhelper command for this task. Right?


Regards

Mats E Andersson


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

Re: request for review: lbzip2-0.16rc1-1

[ERSEK Laszlo]

On Thu, 22 Oct 2009, Paul Wise wrote:


Please note that you need to remove the patches after running make
clean, since you patch the Makefile.


(1) Is it acceptable if I make the "clean" target in debian/rules depend 
on the "unpatch" target, which is defined by /usr/share/quilt/quilt.make 
and seems to do the right thing?


(2) How do you make pbuilder build the package twice in a row?



I get some GCC warnings when I add -Wall to the CFLAGS, like most
Debian source packages have.


I develop with Makefile.dev:

CFLAGS=$$($(SHELL) lfs.sh CFLAGS) -D _XOPEN_SOURCE=500 -pipe -ansi -pedantic \
-fno-builtin -fhosted -Wall -Wextra -Wfloat-equal -Wundef -Wshadow \
-Wlarger-than-32767 -Wpointer-arith -Wbad-function-cast -Wcast-qual \
-Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes \
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Wformat=2 \
-Wunreachable-code -Winline -Wlong-long -g3

Whatever warnings remain do so because I know about them and deem them 
unimportant. I'd suppress them if I could *locally* (or perhaps not, even 
so). The warnings you mention are probably:


- Unused parameters. In allocation callbacks for lacos_rbtree and libbz2 
an opaque pointer is accepted. In lbzip2 I don't use them, so I named such 
parameters "ignored".


- "condition always true/false due to limited range of data type", and as 
a consequence to this, code blocks that "will never be executed". These 
are sanity checks that protect against integer overflows before 
multiplications and additions. If, for example, size_t is 64-bit wide and 
unsigned int is 32-bit wide, then sometimes such checks can be proven 
unconditionally true or false at compile time, hence the warnings. (And 
the dependent block will never execute.) Many of these could be solved 
nicer if the preprocessor knew about (size_t)-1, or  defined 
SIZE_MAX. (SSIZE_MAX is very different.)


I left -Wall out of Makefile and Makefile.portable on purpose.

(If you ask why three standalone makefiles: I can't use "include" in the 
makefiles for the rules as "include" is not SUSv2.)




I personally think you could merge the Makefile patch upstream. I've
attached what I think the Makefile and rules file would look like if
you do that.


Thank you.


Ad upstream Makefile:

* -Wall: see above

* PREFIX=/usr/local:

I never install packages I compile from source under /usr/local as they 
are effectively un-removable after installation (or I have to keep the 
configured source tree for an eventual "make uninstall"). I always do a 
variant of /opt/vendor/package, or simply $HOME/installed/package-version, 
and I either extend my PATH, MANPATH, INFOPATH etc. or create symlinks. Of 
course, you can do this by overriding PREFIX, but at packages this size I 
always hand-pick what I install (or if the project uses autoconf and 
stuff, I fix it up after "make install").


For example, "make install" often doesn't install the upstream README, and 
I like to keep them (and others don't). So I rather give a description in 
the README what's what and the user can choose. I don't feel like 
torturing my brain with autoconf for a project this size (even less so as 
I can't see any use in it, lbzip2 being coded against SUSv2).


I accept that most users don't *want* to make choices. This is why I'd 
like if Debian provided lbzip2 for them, and I do strive to package as you 
say.


* sanity check: test.sh does this and more, and is available through the 
Makefile, and documented in the README.



Ad debian/rules:

If you want me to, (3) I can add -Wall, and also (4) let dh_installman 
find lbzip2.1 on its own.



If you were to throw autotools into the mix, you could get rid of the 
first hunk of the manual page patch too. For the second hunk, manual 
pages can contain a BUGS section. I understand completely if you do not 
want to adopt my changes.


autotools I've covered above. For the second hunk: the sentence referring 
to the README's Bugs section is already in the manual page's BUGS section; 
that's why the phrase ends with "for more on this": the verbiage I've put 
under README/Bugs would be a bit too much for the manual, I believe.



I respectfully ask for your help with (1)-(4) so I can re-upload the 
package.


Thanks a lot!
lacos


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

Re: request for review: lbzip2-0.16rc1-1

[ERSEK Laszlo]

On Thu, 22 Oct 2009, ERSEK Laszlo wrote:

(1) Is it acceptable if I make the "clean" target in debian/rules depend on 
the "unpatch" target, which is defined by /usr/share/quilt/quilt.make and 
seems to do the right thing?


Or rather, as the (new) last action of the "clean" target, invoke

$(MAKE) unpatch

So that the inverse of "patch, then build" is correctly ordered as "clean, 
then unpatch"; especially because the Makefile and its "clean" target are 
patched as well.


Thanks,
lacos


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

Re: Library builds with pkg-config

[Paul Wise]

Usually the upstream build system would do this. If it does not then
I'd suggest that you talk to upstream about including the pkgconfig
file before putting it in Debian.

-- 
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: ampache (updated package)

[Raphael Geissert]

Hi Manoj,

Manoj Srivastava wrote:

> On Tue, Oct 20 2009, Raphael Geissert wrote:
> 
>> Hi Manoj,
>>
>> Manoj Srivastava wrote:
>> [...]
>>> 
>>> I find that experimental and pedantic add far too much
>>>  irrelevant chatter, and that it tends to mask the problems one should
>>>  actually fix.
>>> 
>>
>> Could you please elaborate a bit more? I'd like to know how I can improve
>> lintian so that it is more useful for others.
> 
> ,[  Manual page lintian(1)  ]
> |  --pedantic
> | Display pedantic ("P:") tags as well.  They are normally
> | suppressed.
> | 
> | Pedantic tags are Lintian at its most pickiest and include
> | checks for particular Debian packaging styles, checks that are
> | very frequently wrong, and checks that many people disagree
> | with.  Expect false positives and Lintian tags that you don't
> | consider useful if you use this option.  Adding overrides for
> | pedantic tags is probably not worth the effort.
> `
> 
> Pretty much covers it, neh?
> 
> Also:
> 
> ,[ http://lintian.debian.org/manual/ch2.html#s2.3 ]
> | Experimental:
> |   This means that the code that generates this message is not as well
> |   tested as the rest of Lintian, and might still give surprising
> |   results. Feel free to ignore Experimental messages that do not seem to
> |   make sense, though of course bug reports are always welcomed.
> `

Well, experimental checks are not to be considered "irrelevant chatter",
hence my question.

The current experimental checks are:
Tag: spelling-error-in-binary
Severity: normal
Certainty: wild-guess

It is based on the output of strings(1) so it can't tell for sure whether a
string is actually displayed or it is just a symbol or something else, or
whether it is really an error or not (although it is pretty accurate in
most cases).

--

Tag: template-uses-unsplit-choices
Severity: normal
Certainty: possible

Erm, IIRC this one should no longer be marked as experimental ever since
lenny was released.

--

Tag: embedded-pear-module
Severity: normal
Certainty: possible

PEAR modules are a bit tricky to detect properly without making it too
specific, in which case the check itself wouldn't be of much use.

--
Tag: shlib-calls-exit
Severity: wishlist
Certainty: possible

There's no way for lintian to tell whether the usage of exit or _exit is
correct at all in the shared library, and it is based only by looking at
the symbols.

> 
> Now, people experienced in packaging stuff for Debian ought to
>  be looking at pedantic and experimental tags and giving feedback to
>  Lintian, to improve it (I certainly do). But I only look at
>  experimental and pedantic tags when I want to see f I want to give
>  feedback to Lintian, not as a package check. As a package check it is
>  very inefficient, and definitely not what I would recommend to a
>  novice.

I would personally recommend checking pedantic tags here in mentors, it is a
great way to introduce people to best practises. If anyone refuses to make
the change suggested by lintian elaborating a bit more why could be a good
exercise as well.

As a reference, the current pedantic checks are:
 no-upstream-changelog
 experimental-to-unstable-without-comment
 debian-control-has-unusual-field-spacing
 copyright-refers-to-symlink-license
 source-contains-cvs-control-dir
 source-contains-svn-control-dir
 source-contains-bzr-control-dir
 source-contains-arch-control-dir
 source-contains-git-control-dir
 source-contains-hg-control-dir
 source-contains-bts-control-dir
 source-contains-svn-commit-file
 source-contains-svk-commit-file
 source-contains-arch-inventory-file
 source-contains-hg-tags-file
 source-contains-cvs-conflict-copy
 source-contains-svn-conflict-file
 source-contains-prebuilt-binary
 source-contains-prebuilt-windows-binary
 no-homepage-field
 direct-changes-in-diff-but-no-patch-system
 example-unusual-interpreter
 example-interpreter-in-usr-local
 example-shell-script-fails-syntax-check
 maintainer-script-without-set-e

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



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

Re: Lintian pickiness and packaging improvements

[Raphael Geissert]

> Pedantic tags are Lintian at its most pickiest and include
> checks for particular Debian packaging styles, *checks that are
> very frequently wrong*, and checks that many people disagree
> with.  Expect false positives and Lintian tags that you don't
> consider useful if you use this option.  Adding overrides for
> pedantic tags is probably not worth the effort.

As the person who pushed and introduced pedantic support I always felt a bit
hesitant regarding the highlighted statement, maybe I should bring this up
on the lintian mailing list and ask Russ for his reasons behind it (maybe
what he wanted to express could be paraphrased).
If a check is wrong I don't think it should belong to the pedantic category,
IMHO.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



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

Re: RFS: ampache (updated package)

[Manoj Srivastava]

On Wed, Oct 21 2009, Raphael Geissert wrote:

> Hi Manoj,
>
> Manoj Srivastava wrote:
>
>> On Tue, Oct 20 2009, Raphael Geissert wrote:
>> 
>>> Hi Manoj,
>>>
>>> Manoj Srivastava wrote:
>>> [...]
 
 I find that experimental and pedantic add far too much
  irrelevant chatter, and that it tends to mask the problems one should
  actually fix.
 
>>>
>>> Could you please elaborate a bit more? I'd like to know how I can improve
>>> lintian so that it is more useful for others.
>> 
>> ,[  Manual page lintian(1)  ]
>> |  --pedantic
>> | Display pedantic ("P:") tags as well.  They are normally
>> | suppressed.
>> | 
>> | Pedantic tags are Lintian at its most pickiest and include
>> | checks for particular Debian packaging styles, checks that are
>> | very frequently wrong, and checks that many people disagree
>> | with.  Expect false positives and Lintian tags that you don't
>> | consider useful if you use this option.  Adding overrides for
>> | pedantic tags is probably not worth the effort.
>> `
>> 
>> Pretty much covers it, neh?
>> 
>> Also:
>> 
>> ,[ http://lintian.debian.org/manual/ch2.html#s2.3 ]
>> | Experimental:
>> |   This means that the code that generates this message is not as well
>> |   tested as the rest of Lintian, and might still give surprising
>> |   results. Feel free to ignore Experimental messages that do not seem to
>> |   make sense, though of course bug reports are always welcomed.
>> `
>
> Well, experimental checks are not to be considered "irrelevant chatter",
> hence my question.
>
> The current experimental checks are:
> Tag: spelling-error-in-binary
> Severity: normal
> Certainty: wild-guess
>
> It is based on the output of strings(1) so it can't tell for sure whether a
> string is actually displayed or it is just a symbol or something else, or
> whether it is really an error or not (although it is pretty accurate in
> most cases).

Such has not been my experience. It keep blathering about how
 the suport (su port) needs to be called support, which, in the 8 (count
 it: eight) times it occurs in my packages is rubbish.




> Tag: template-uses-unsplit-choices
> Severity: normal
> Certainty: possible
>
> Erm, IIRC this one should no longer be marked as experimental ever since
> lenny was released.

So, this is a bug in lintian, really, and one should not need
 experimental errors to see this.

> Tag: embedded-pear-module
> Severity: normal
> Certainty: possible
>
> PEAR modules are a bit tricky to detect properly without making it too
> specific, in which case the check itself wouldn't be of much use.

So, lots of false positives?

> Tag: shlib-calls-exit
> Severity: wishlist
> Certainty: possible
>
> There's no way for lintian to tell whether the usage of exit or _exit
> is correct at all in the shared library, and it is based only by
> looking at the symbols.

Again a code I have to ignore.

> I would personally recommend checking pedantic tags here in mentors,
> it is a great way to introduce people to best practises. If anyone
> refuses to make the change suggested by lintian elaborating a bit more
> why could be a good exercise as well.

I have found pedantic flags often not to be good practices, but
 practices that various lintian authors have liked. And thus one should
 only be exposed to them when one has the judgment to decide  whether or
 not it is an idiosyncracy or good practice.

manoj
-- 
If you always postpone pleasure you will never have it.  Quit work and
play for once!
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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