Re: How to be a great Debian Developer

[Thomas Viehmann]

Hi Chad.

I did not answer to your first post for various reasons.
While I thank you for your answers, I strongly disagree
with some of your views to the point that I wondered why
it was my package that prompted you to write about "pet-packages".

Just as your advice was not only to me, please take these comments as
something that I'd like to say not only about your comments, but also
as an observation of the general way of discussion.

Taking your answer literally, the conclusion is that you think that debian
has enough package maintainers and the others should bother about the crums
that fall from the table that existing DDs are not interested in.
As for the discussion "package something only you are interested in", I
believe to have explicitly demonstrated why my package is worth including.
In fact, take a look at Bug #174481, which prompted me to package libchipcard
and also take on libopenhbci (the latter of which now James Treacy packaged
due to a wishlist bug but obviously doesn't use it himself).
In short, libchipcard does provide a value to debian, as it adds a unique
functionality, and, I believe, is needed top make the gnucash-hbci package
worthwhile as most banks offering HBCI tend to offer it via chipcard-based
methods. (Which I cannot blame you for not knowing, though.)
I've thought about packaging quite a few things before, but now I think I've
found something truely worthwhile.

Also, I'd like to address the call for "writing manpages for other packages"
and caring about wnpp packages:
Why would you expect anyone to write the manpages the package maintainer
doesn't bother about? True, there are those maintainers that don't have the
time because they're doing very much for the project, but for the most part,
I cannot help but think that they just don't care. I did write two manpages
for my own package because that is the lintian warning that's still left, but
you should well know that a volunteer project needs to distribute the dull
jobs amongst those that are working for the main cause.
Being told "do something but just don't have packages" is just like asking the
local LUG (or whatever) whether you can help out at an expo booth and getting
"well, as long as you just don't come to the booth during the show but just
the vacuuming afterwards" as an answer.
With wnpp matters are even worse, because for the most part, they are just
"ugly, pointless packages noone in the world would care about". (There are
notable exceptions every once in a while, but mostly this is the exact reason
they're abandoned in the first place.)

In addition, "helping out maintainers" is something that strongly depends on
the willingness of maintainers to accept help. In my experience, the quality
of the packages is strongly correlated (maybe even causal, not coincidental)
to the willingness of maintainers to accept help and user comments and their
friendlyness to answer questions. Let's face it, the main cause of problems in
debian are the problems of and with the present developers and do not relate
very well to future developers.

Again. I've not answered directly because I personally don't have any issue
with this, if I don't find a sponsor and I just keep using my packages myself,
it's just the same work for me. If you like to give out funny advice, please
do so, people are doing everywhere on the net. But don't expect anyone to join
debian just to do the odd jobs and wanting to be "a slave to Debian". And
don't think that telling people "the contribution you want to offer is not
needed, please do the stuff we don't like" is a successful way of getting
anywhere.

Again, please don't take offence, I don't mind your answer in itself, I just
want to point out some issues with the impression that potential volunteers
get when considering to apply for debian membership.

Cheers

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to be a great Debian Developer

[Russell Coker]

On Tue, 28 Jan 2003 08:55, Thomas Viehmann wrote:
> still left, but you should well know that a volunteer project needs to
> distribute the dull jobs amongst those that are working for the main cause.

That is a fair point.  However you may have noticed that there are 
difficulties in becoming a new Debian developer.  Doing some of the dull jobs 
may make that easier for you.

> In addition, "helping out maintainers" is something that strongly depends
> on the willingness of maintainers to accept help. In my experience, the
> quality of the packages is strongly correlated (maybe even causal, not
> coincidental) to the willingness of maintainers to accept help and user
> comments and their friendlyness to answer questions.

That is true to a certain extent.  However there are some packages that are so 
difficult to maintain that even with a lot of help and a lot of hard work 
there will still be plenty of bugs left to fix.  Glibc and X spring to mind.

> Again, please don't take offence, I don't mind your answer in itself, I
> just want to point out some issues with the impression that potential
> volunteers get when considering to apply for debian membership.

To a large extent the Debian developers don't have direct control over this 
anyway.  Search the archives and you'll find plenty of flame-wars on this 
topic.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

How to debug apt-get dependencies

[Karolina Lindqvist]

The subject line says it all. I have a condition where apt-get refuses to 
upgrade. How can I figure out exactly what apt-get does not like:

Here follows my example run. The reason I use a versioned install is just 
because otherwise apt-get just refuses to consider the upgrade. This is a 
problem I have gotten before and found it quite hard to figure out the 
reason, and is never sure if I really got the right solution. There must be a 
way to figure out exactly what goes wrong.

First:
shakti:~# dpkg --compare-versions '4:3.1.0++kl-1' '>' '4:3.1.0+rc6+kl-3'; echo 
"$?"
0

Ok, version 4:3.1.0++kl-1 is the greater version.
Now:

shakti:~# apt-get install -t unstable libkdecore4
Reading Package Lists... Done
Building Dependency Tree... Done
Sorry, libkdecore4 is already the newest version.
Done
0 packages upgraded, 0 newly installed, 0 to remove and 58  not upgraded.

Ooops. already the newest version?
But what about the following, and the compare-version above:

shakti:~# apt-cache show libkdecore4 | grep Version
Version: 4:3.1.0++kl-1
Version: 4:3.1.0+rc6+kl-3
shakti:~#

Let's try this:

shakti:~# apt-get install -t unstable libkdecore4=4:3.1.0++kl-1

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

Sorry, but the following packages have unmet dependencies:
  libkdecore4: Depends: libdcop4 (>= 4:3.1.0++kl) but 4:3.1.0+rc6+kl-3 is to 
be installed
   Depends: libkdefx4 (>= 4:3.1.0++kl) but 4:3.1.0+rc6+kl-3 is to 
be installed
   Depends: kdeinit4 (= 4:3.1.0++kl-1) but 4:3.1.0+rc6+kl-3 is to 
be installed
   Depends: libkdecore-data but it is not going to be installed
E: Sorry, broken packages

Note here that all those missing packages are existing, and according to the 
dpkg compare-version above, have higher version numbers. apt-get is doing the 
wrong thing above. Why is it not updating those packages shown, libdcop4, 
libkdefx4 and kdeinit4, when there are newer version available that will 
satisfy the dependencies?

the full output of the run follows in the end


Karolina


shakti:~# apt-get install -t unstable libkdecore4=4:3.1.0++kl-1
Reading Package Lists... Done
Building Dependency Tree... Done
Starting
Starting 2
Investigating libkdecore4
Package libkdecore4 has broken dep on libdcop4
  Considering libdcop4 2082 as a solution to libkdecore4 11796
Package libkdecore4 has broken dep on libkdefx4
  Considering libkdefx4 2079 as a solution to libkdecore4 11796
Package libkdecore4 has broken dep on kdeinit4
  Considering kdeinit4 1024 as a solution to libkdecore4 11796
Investigating libkdecore-data
Package libkdecore-data has broken dep on libkdecore4
  Considering libkdecore4 11796 as a solution to libkdecore-data 285
  Removing libkdecore-data rather than change libkdecore4
Investigating kdelibs4
Package kdelibs4 has broken dep on libkdecore4
  Considering libkdecore4 11796 as a solution to kdelibs4 3
  Removing kdelibs4 rather than change libkdecore4
Investigating kdelibs-dev
Package kdelibs-dev has broken dep on libkdecore4
  Considering libkdecore4 11796 as a solution to kdelibs-dev 3
  Removing kdelibs-dev rather than change libkdecore4
Investigating ksms
Package ksms has broken dep on kdelibs4
  Considering kdelibs4 3 as a solution to ksms 0
  Removing ksms rather than change kdelibs4
Investigating kio-locate
Package kio-locate has broken dep on kdelibs4
  Considering kdelibs4 3 as a solution to kio-locate 0
  Removing kio-locate rather than change kdelibs4
Investigating libkdegames-dev
Package libkdegames-dev has broken dep on kdelibs-dev
  Considering kdelibs-dev 3 as a solution to libkdegames-dev 0
  Removing libkdegames-dev rather than change kdelibs-dev
Investigating libkscan-dev
Package libkscan-dev has broken dep on kdelibs-dev
  Considering kdelibs-dev 3 as a solution to libkscan-dev 0
  Removing libkscan-dev rather than change kdelibs-dev
Investigating kickpim
Package kickpim has broken dep on kdelibs4
  Considering kdelibs4 3 as a solution to kickpim 0
  Removing kickpim rather than change kdelibs4
Investigating koffice-dev
Package koffice-dev has broken dep on kdelibs-dev
  Considering kdelibs-dev 3 as a solution to koffice-dev 0
  Removing koffice-dev rather than change kdelibs-dev
Investigating libkdecore4
Package libkdecore4 has broken dep on libdcop4
  Considering libdcop4 2082 as a solution to libkdecore4 11796
Package libkdecore4 has broken dep on libkdefx4
  Considering libkdefx4 2079 as a solution to libkdecore4 11796
Package libkdecore4 has broken dep on kdeinit4
  Considering kdeinit4 1024 as a solution to libkdecore4 11796
Package libk

Re: How to be a great Debian Developer

[Chad Miller]

Hi, Thomas.

On Tue, Jan 28, 2003 at 08:55:32AM +0100, Thomas Viehmann wrote:
> Taking your answer literally, the conclusion is that you think that debian
> has enough package maintainers and the others should bother about the crums
> that fall from the table that existing DDs are not interested in.

I don't think Debian is necessarily better off for gaining more main-
tainers.  More maintainers who are productive are great, but maintaining
a package currently means that no one else maintains it (6-month waits
and NMUs aside), and that one person "owning" a package and poorly
packaging it or neglecting it means that a package that is potentially
very useful is useless.

Unfortunately, it's hard to tell who is serious about Debian and who is, 
for instance, likely to do work for a month, decide RedHat is what they
want to run at home, and never be seen again.  

A long NM process used to weed out people joining Debian on a whim
(good), but it also weeded out good developers with a low tolerance for
bureaucracy (very, very bad).  Now that it's relatively simple again, I
thought I'd send a cautionary note to new maintainers, asking them to
consider carefully why they're applying.

There _is_ more to do than "crumb"-work, but everyone has to do the work
that is no fun at all, too.  When newbies realize this, they're not as
likely to stick around.

>[...]
> I've thought about packaging quite a few things before, but now I think I've
> found something truely worthwhile.

That's great.  If you want to maintain it yourself, then welcome to
Debian!

> Why would you expect anyone to write the manpages the package maintainer
> doesn't bother about? True, there are those maintainers that don't have the
> time because they're doing very much for the project, but for the most part,
> I cannot help but think that they just don't care. I did write two manpages
> for my own package because that is the lintian warning that's still left, but
> you should well know that a volunteer project needs to distribute the dull
> jobs amongst those that are working for the main cause.

No it's not fun work, but someone has to do it.  I'm not claiming that
all current maintainers do things correctly -- quite the opposite.

(Some people in Debian suggest that N months of that sort of work should
be a prerequisite for getting the ability to upload new packages.  It's 
informal grumbling, so don't expect it in the NM rules soon.)

I was pointing out that there are ways to help Debian for which one
doesn't have to go through NM.  

> With wnpp matters are even worse, because for the most part, they are just
> "ugly, pointless packages noone in the world would care about". (There are
> notable exceptions every once in a while, but mostly this is the exact reason
> they're abandoned in the first place.)

This is true.  A significant fraction of the packages you see are the
tangible results of Joe Debian packaging his own software.  

More software authors filing RFP bugs instead of NM applications would
help.  The request/claim buffer of WNPP would keep out a lot of "useless"
stuff.
 
> In addition, "helping out maintainers" is something that strongly depends on
> the willingness of maintainers to accept help. In my experience, the quality
> of the packages is strongly correlated (maybe even causal, not coincidental)
> to the willingness of maintainers to accept help and user comments and their
> friendlyness to answer questions. 

Yes, and if you're on debian-mentor, you're probably a personality that
doesn't mind getting help, so I have nothing to add here.
 
>Let's face it, the main cause of problems in
> debian are the problems of and with the present developers and do not relate
> very well to future developers.

I've said "these are the problems."   Will readers of this contribute to
the problems or help reduce them?

>[...]   Don't expect anyone to join
> debian just to do the odd jobs and wanting to be "a slave to Debian". And
> don't think that telling people "the contribution you want to offer is not
> needed, please do the stuff we don't like" is a successful way of getting
> anywhere.

I guess that depends on what I consider "success".

I don't want to send away good developers, but in my estimation when
four people join, the first is productive, the second is an obstacle, and
the third and forth (who could have been productive) are stuck cleaning
up after the second.

I really want a way to avoid #2.  I fear there isn't one, though.

- chad


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: OpenEXR beta packages.

[Andrew Lau]

On Mon, Jan 27, 2003 at 04:30:32PM +0100, Jesus Climent wrote:
> They are lintian clean, but linda reports an odd error.

Let me guess,

netsnipe@espresso:/usr/src/debian-devel/active% linda -i
libopenexr0_1.0.4-1_i386.deb
X: libopenexr0; Package name doesn't contain one of the SONAMEs.
 This package isn't named after one of the SONAMEs of the shared
 library, or the SONAME has changed and the package name hasn't.

I talked to StevenK about this and he pointed out that it may be a
Linda bug. X is for experimental after all. My guess is because
libopenexr0 does not contain a libopenexr.so.0 file as such.

> I had a bit of troubles tracking down to bugs already reported to
> upstream:
> * -O2 code cannot be compiled using gcc3.2.

I had no such problem here.

> * exrdisplay segfaults if there are no type1 fonts installed.

Haven't tested this one yet.

> If you manage to find a better solution, please report it.

I already had most of my OpenEXR packages completed before I find out
about your ITP and going through your .diff.gz now, it seems like you
could do with a lot more polishing and some experince.

* Real minor, but why 1.0.4-2 and not -1? Debian doesn't have any
  OpenEXR packages already.

* Upstream's orig tarball contained no config.guess or config.sub, so
  your patch should not include them.

* Remove all those sample and unneccesary debhelper files such as all
  the dirs files and postinst.

* Clean up those commented commands in debian/rules. The aim is to
  keep the diff.gz as small and clean as possbile. It's also better to
  use dh_install instead of dh_movefiles

* Your manpage could at least describe how to use
  exrdisplay.  What you have now is
  plain laziness = P

* HTML should go into /usr/share/package/doc/HTML/. I don't think
  they're getting installed anyway since you only have debian/doc and
  not debian/exrdisplay.doc

* Read Junichi Uekawa's Debian Library Packaging guide carefully!
  http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

Did you pick the name libopenexr1 randomly? The SONAME on
those libs was 0 as far as I could tell!

Call the package libopenexr0-dev as well, and
Provides/Replaces libopenexr-dev as Junichi recommends.

* libopenexr0-dev should Depends: libopenexr0 (= ${Source-Version}),
  xlibmesa-gl-dev, xlibmesa-glu-dev. "grep #include
  /usr/include/OpenEXR/*" to see why.

Please fix all of this as soon as possible. Sorry if I sound
impatient, but I really need to get OpenEXR support into my Film Gimp
0.15-1 packages, and I won't hesitate to upload my packages instead if
I have to. However, I am willing to help you improve (or even
co-maintain) your next batch of OpenEXR packages.

Cheers,
Andrew "Netsnipe" Lau

--
---
* Andrew "Netsnipe" Lau  Computer Science & Student Rep, UNSW *
*   # apt-get into it Debian GNU/Linux Package Maintainer *
**
* GnuPG 1024D/2E8B68BD 0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D 2E8B 68BD *
---




msg08409/pgp0.pgp
Description: PGP signature

RE: How to be a great Debian Developer

[deFreese, Barry]

>[...]   Don't expect anyone to
join
> debian just to do the odd jobs and wanting to be "a slave to Debian". And
> don't think that telling people "the contribution you want to offer is not
> needed, please do the stuff we don't like" is a successful way of getting
> anywhere.

>-Original Message-
>From: Chad Miller [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, January 28, 2003 7:11 AM
>To: Thomas Viehmann
>Cc: debian-mentors
>Subject: Re: How to be a great Debian Developer
>
>I guess that depends on what I consider "success".
>
>I don't want to send away good developers, but in my estimation when
>four people join, the first is productive, the second is an obstacle, and
>the third and forth (who could have been productive) are stuck cleaning
>up after the second.
>
>I really want a way to avoid #2.  I fear there isn't one, though.
>
>   - chad


Hey I've offer to be a "slave" to Debian but no one seems to be taking me
seriously.  I'll write man pages, clean up code, test, whatever, I just need
some guidance in the right direction.  The way I look at it, the more
exposure I get, the more I learn.  The more I learn through doing the grunt
work then maybe I get better can move to more of a developer and then
someone else can pick up the grunt work.

Barry deFreese
NTS Technology Services Manager
Nike Team Sports
(949)-616-4005
[EMAIL PROTECTED]

"Technology doesn't make you less stupid; it just makes you stupid faster."
Jerry Gregoire - Former CIO at Dell





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to be a great Debian Developer

[Tom Marshall]

> Unfortunately, it's hard to tell who is serious about Debian and who is, 
> for instance, likely to do work for a month, decide RedHat is what they
> want to run at home, and never be seen again.  
> 
> A long NM process used to weed out people joining Debian on a whim
> (good), but it also weeded out good developers with a low tolerance for
> bureaucracy (very, very bad).  Now that it's relatively simple again, I
> thought I'd send a cautionary note to new maintainers, asking them to
> consider carefully why they're applying.

I sent a message to -devel on this subject some four weeks ago.  Please see:

http://lists.debian.org/debian-devel/2003/debian-devel-200301/msg00125.html

The bottom line is that I'm most concerned with the unbounded wait times
(I suppose that puts me in your latter category).  I would not mind waiting
a few months if I knew that the process could not take any longer than, say,
6 months.  I'm not anxious to apply when there are people who have been
waiting for over a year with no indication of when they may be accepted or
rejected.  That's not just bureaucracy, it borders on cruelty.

The thread referenced above seems to have died and I haven't heard anything
on the subject in a couple of weeks, even though (it appears) most people
are sympathetic.  I'm sticking around for a little while, just in case, but
I am rapidly coming to the conclusion that I should let an existing DD
package my app and be done with it.  :-/

-- 
"... developing software for Microsoft [Windows] is like brushing the teeth
of a Great White Shark with a piece of raw steak."
-- Robert G. Brown, LinuxToday



msg08411/pgp0.pgp
Description: PGP signature

Re: How to be a great Debian Developer

[Stephen Gran]

This one time, at band camp, deFreese, Barry said:
> Hey I've offer to be a "slave" to Debian but no one seems to be taking
> me seriously.  I'll write man pages, clean up code, test, whatever, I
> just need some guidance in the right direction.  The way I look at it,
> the more exposure I get, the more I learn.  The more I learn through
> doing the grunt work then maybe I get better can move to more of a
> developer and then someone else can pick up the grunt work.

Check out
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=wnpp&archive=no
for a list of packages that are requested, orphaned, or otherwise
need some help to get into the archive.

http://www.debian.org/Bugs/pseudo-packages
for a list of other so-called pseudo packages (things like the mailing
lists, or the boot cd's) and a list of unresolved bugs on them.  Some of
these need quite a bit of work (like the boot cd's) from what I
understand, so help there might be appreciated.

That's at least a start.  I'm sure there must be a way to get a list of
bugs with a specific tag; e.g 'help' or 'unreproducable' that need some
help to fix, but I can't find it right now.  Colin, is that possible?

-- 
 --
|  Stephen Gran  | The problem with the gene pool is that  |
|  [EMAIL PROTECTED] | there is no lifeguard.  |
|  http://www.lobefin.net/~steve | |
 --



msg08412/pgp0.pgp
Description: PGP signature

Re: How to be a great Debian Developer

[Russell Coker]

On Tue, 28 Jan 2003 17:55, deFreese, Barry wrote:
> Hey I've offer to be a "slave" to Debian but no one seems to be taking me
> seriously.  I'll write man pages, clean up code, test, whatever, I just

One thing you could do is write a script that searches for a man page for 
every binary on your system.  /usr/bin and /bin binaries deserve man pages in 
section 1, /usr/sbin and /sbin binaries deserve man pages in section 8.  If 
you write a Perl script to search for such man pages you will should find 
hundreds of them to be missing on a typical system (there's more than a few 
missing from my packages).  Then start writing some man pages!

Also publish the script, I'm sure other people would find it useful.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to be a great Debian Developer

[Colin Watson]

On Tue, Jan 28, 2003 at 01:03:11PM -0500, Stephen Gran wrote:
> That's at least a start.  I'm sure there must be a way to get a list of
> bugs with a specific tag; e.g 'help' or 'unreproducable' that need some
> help to fix, but I can't find it right now.  Colin, is that possible?

Not for tags in general, but lists for 'help', 'security', and
'unreproducible' are linked off http://qa.debian.org/ (the third set of
links under "Work needed").

Cheers,

-- 
Colin Watson  [[EMAIL PROTECTED]]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to be a great Debian Developer

[Bas Zoetekouw]

Hi Russell!

You wrote:

> One thing you could do is write a script that searches for a man page for 
> every binary on your system.  /usr/bin and /bin binaries deserve man pages in 
> section 1, /usr/sbin and /sbin binaries deserve man pages in section 8.  If 
> you write a Perl script to search for such man pages you will should find 
> hundreds of them to be missing on a typical system (there's more than a few 
> missing from my packages).  Then start writing some man pages!

There is already such a script, see http://qa.debian.org/man-pages.html

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: How to be a great Debian Developer

[deFreese, Barry]

Bas,

I've looked at this page and had a brief discussion with Bastian on it.  I'm
somewhat of a noob to Linux and really green on the development side so my
question was.  How do I know if any of these packages listed on this page
are even still in use?  Many of the bug reports for a lot of these packages
are well over a year old.  Also, I need to start on some that are a little
smaller to align with my current skills (or lack thereof) to get started.
Any suggestions?

Thanks!!

Barry deFreese
NTS Technology Services Manager
Nike Team Sports
(949)-616-4005
[EMAIL PROTECTED]

"Technology doesn't make you less stupid; it just makes you stupid faster."
Jerry Gregoire - Former CIO at Dell



-Original Message-
From: Bas Zoetekouw [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 11:35 AM
To: Russell Coker
Cc: deFreese, Barry; '[EMAIL PROTECTED]'
Subject: Re: How to be a great Debian Developer


Hi Russell!

You wrote:

> One thing you could do is write a script that searches for a man page for 
> every binary on your system.  /usr/bin and /bin binaries deserve man pages
in 
> section 1, /usr/sbin and /sbin binaries deserve man pages in section 8.
If 
> you write a Perl script to search for such man pages you will should find 
> hundreds of them to be missing on a typical system (there's more than a
few 
> missing from my packages).  Then start writing some man pages!

There is already such a script, see http://qa.debian.org/man-pages.html

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Question about lintian's shell-script-fails-syntax-check

[Marco Kuhlmann]

Hi all.

A package of mine, mozart, uses some rather informal shell scripts.  The
idea is to provide a wrapper around one of their tools, ozengine -- the
shell script passes its arguments and a kind of initialisation code to
ozengine.  To illustrate this, the beginning of one script looks like
follows:

#!/bin/sh
exec ozengine $0 "$@"
^B^B^B^K^?<83>?^_<8B>^H^@^@^@^@^@^@^C<9D>}^G|TU;<9E><97>

So from the third line on, each of these shell scripts is syntax error. :-)
Since recently, lintian takes offence in such syntax errors.  What am I
supposed to do?  The scripts seem to work fine in spite of their syntax
errors, but I am not sure how to convince lintian about that.

Thanks for any advice,
Marco



msg08417/pgp0.pgp
Description: PGP signature

joining Debian / packaging buildd

[Jeremy Lainé]

Hi!

I am interested in becoming a Debian developer and have already
produced a number of Debian packages, but they fall in the "pet
packages" category referred to in another thread on this list. The
most recent ones are mpf70-source and mpf70-utils, respectively the
source for a kernel module (builds with make-kpkg) and some userspace
utilities for the MPman MP-F70 portable MP3 player:

deb http://dev.jerryweb.org/debian ./ 
deb-src http://dev.jerryweb.org/debian ./ 

As far as I can tell, these packages are pretty much ready, but I am
putting them on hold until someone else expresses interest in them, so
as not to clutter the Debian archive pointlessly.

In the meantime, I think I've found something to sink my teeth in,
namely packaging buildd. I realise it's a big bugger, but as packaging
it seems to have been on the TODO list for a while I suppose any work
I put into it is that much done.. I am looking for a contact from the
buildd team to ask whether I can rename some files, or whether this is
not a purely Debian package and needs to be handled like a package
with an upstream and a Debian diff.

Jeremy

--  
http://www.jerryweb.org/ : JerryWeb.org
http://sailcut.sourceforge.net/  : Sailcut CAD
http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: OpenEXR beta packages.

[Michel Dänzer]

On Die, 2003-01-28 at 17:35, Andrew Lau wrote:

> * libopenexr0-dev should Depends: libopenexr0 (= ${Source-Version}),
>   xlibmesa-gl-dev, xlibmesa-glu-dev. "grep #include
>   /usr/include/OpenEXR/*" to see why.

You probably mean libgl-dev and libglu-dev instead of xlibmesa-gl-dev
and xlibmesa-glu-dev?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about lintian's shell-script-fails-syntax-check

[Bastian Kleineidam]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marco,

On Tue, Jan 28, 2003 at 09:39:15PM +0100, Marco Kuhlmann wrote:
> The scripts seem to work fine in spite of their syntax
> errors, but I am not sure how to convince lintian about that.
Read file:///usr/share/doc/lintian/lintian.html/ch2.html#s2.4
for lintian overrides.


Cheers, Bastian
- -- 
 Bastian Kleineidam

 Atombombe · Plutonium · Fat Man · Do it Yourself · Tim Taylor
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Nvt4eBwlBDLsbz4RAh2jAJ0QSg3DHTDfTR+jcpPU4bWhm1wQ9QCZAbiI
H2vDo/WygF0alSZcfGhBdas=
=mWrO
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: joining Debian / packaging buildd

[Roger Leigh]

Jeremy Lainé <[EMAIL PROTECTED]> writes:

> In the meantime, I think I've found something to sink my teeth in,
> namely packaging buildd. I realise it's a big bugger, but as packaging
> it seems to have been on the TODO list for a while I suppose any work
> I put into it is that much done..

You might be interested in

http://www.whinlatter.uklinux.net/buildd/

This doesn't yet automate all of the setup properly, and is a bit out
of date with my local CVS, but does work with a bit of manual setup
after installation.

> I am looking for a contact from the buildd team to ask whether I can
> rename some files, or whether this is not a purely Debian package
> and needs to be handled like a package with an upstream and a Debian
> diff.

You should probably subscribe to buildd-discuss at nocrew.org.


Regards,
Roger

-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Mathwar - Orphaned Package

[David Lloyd]

Hi There,

* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174700

A few really silly questions:

1) Is that package still orphaned?
 - I'd say so because upstream has gone to version 0.2.X

2) I want to adopt it
 - upstream author is happy
 - haven't heard from the maintainer Peter Crystal <[EMAIL PROTECTED]>
   but in absence of correspondence I'm assuming this is still the case

..but I can't work out HOW to do the part that says "Change the O: to
ITA:".

*or* for that matter what to do now.

<-- can someone point me at a newbie guide to sort of adopting an orphaned
packages :0?


dsl
-- 
Microbits Linux Technician

Ph: +61 8 8362 9220


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about lintian's shell-script-fails-syntax-check

[Sean 'Shaleh' Perry]

On Tuesday 28 January 2003 13:51, Bastian Kleineidam wrote:
> Marco,
>
> On Tue, Jan 28, 2003 at 09:39:15PM +0100, Marco Kuhlmann wrote:
> > The scripts seem to work fine in spite of their syntax
> > errors, but I am not sure how to convince lintian about that.
>
> Read file:///usr/share/doc/lintian/lintian.html/ch2.html#s2.4
> for lintian overrides.
>
>
> Cheers, Bastian

or perhaps come up with some logic to detect this kind of odd shell script.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mathwar - Orphaned Package

[Joe Nahmias]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David,

> 1) Is that package still orphaned?
>  - I'd say so because upstream has gone to version 0.2.X
No new information has been sent to the bug since the original report,
and the title still says "O:", so I'd say it is orphaned.

> ..but I can't work out HOW to do the part that says "Change the O: to
> ITA:".
Send a message to [EMAIL PROTECTED], containing something like:
retitle 174700 ITA: mathwar -- A flash card game designed to teach maths.
See  for more info on how to
use [EMAIL PROTECTED]

> *or* for that matter what to do now.
Fix the outstanding bugs (if any), update the package to the latest
upstream version, upload the package with yourself as maintainer
(closing the bug in the process).

> <-- can someone point me at a newbie guide to sort of adopting an orphaned
> packages :0?
See, for example, , especially the
information at the end.

Hope this helps!

Joe Nahmias, DD wannabe :-)
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE+N1t/Kl23+OYWEqURAnWLAKCGZOE5vVpCCr7La/ZAXTPLcvXgVACfetjf
ZBi2yoCN8hChaqtn/Vd39Ok=
=20Re
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to be a great Debian Developer

[Sven Luther]

On Mon, Jan 27, 2003 at 05:48:19PM -0500, Chad Miller wrote:
> Let me give a personal example:  I wrote a program that uses the XMLRPC
> features of Advogato to edit one's diary there.  People loved it.  There
> are about two dozen people who regularly use it.  I made it into a
> package, and put it in my personal repository, rather than upload it.
> Why?  Because two dozen users isn't important enough to use Debian's FTP
> space.  Our repository is HUGE, almost too big to rsync to some mirrors
> regularly.  That hurts users.  My ego and the convenience of a handful of
> people isn't worth wasting even more space.

Well, on the other hand, having it in the archive gives it more
visibility, and maybe more people will try it out and use it than if you
keep it in a separate repository.

Also when i got into a plan to makes my packages smaller, i was told
that unless we spare 20Mo or something such per arch, it is not worth
it (on this list no less) so i have doubts about a little package being
too much for the ftp archive.

Friendly,

Sven Luther

Re: How to be a great Debian Developer

[Thomas Viehmann]

Hi Chad.

I did not answer to your first post for various reasons.
While I thank you for your answers, I strongly disagree
with some of your views to the point that I wondered why
it was my package that prompted you to write about "pet-packages".

Just as your advice was not only to me, please take these comments as
something that I'd like to say not only about your comments, but also
as an observation of the general way of discussion.

Taking your answer literally, the conclusion is that you think that debian
has enough package maintainers and the others should bother about the crums
that fall from the table that existing DDs are not interested in.
As for the discussion "package something only you are interested in", I
believe to have explicitly demonstrated why my package is worth including.
In fact, take a look at Bug #174481, which prompted me to package libchipcard
and also take on libopenhbci (the latter of which now James Treacy packaged
due to a wishlist bug but obviously doesn't use it himself).
In short, libchipcard does provide a value to debian, as it adds a unique
functionality, and, I believe, is needed top make the gnucash-hbci package
worthwhile as most banks offering HBCI tend to offer it via chipcard-based
methods. (Which I cannot blame you for not knowing, though.)
I've thought about packaging quite a few things before, but now I think I've
found something truely worthwhile.

Also, I'd like to address the call for "writing manpages for other packages"
and caring about wnpp packages:
Why would you expect anyone to write the manpages the package maintainer
doesn't bother about? True, there are those maintainers that don't have the
time because they're doing very much for the project, but for the most part,
I cannot help but think that they just don't care. I did write two manpages
for my own package because that is the lintian warning that's still left, but
you should well know that a volunteer project needs to distribute the dull
jobs amongst those that are working for the main cause.
Being told "do something but just don't have packages" is just like asking the
local LUG (or whatever) whether you can help out at an expo booth and getting
"well, as long as you just don't come to the booth during the show but just
the vacuuming afterwards" as an answer.
With wnpp matters are even worse, because for the most part, they are just
"ugly, pointless packages noone in the world would care about". (There are
notable exceptions every once in a while, but mostly this is the exact reason
they're abandoned in the first place.)

In addition, "helping out maintainers" is something that strongly depends on
the willingness of maintainers to accept help. In my experience, the quality
of the packages is strongly correlated (maybe even causal, not coincidental)
to the willingness of maintainers to accept help and user comments and their
friendlyness to answer questions. Let's face it, the main cause of problems in
debian are the problems of and with the present developers and do not relate
very well to future developers.

Again. I've not answered directly because I personally don't have any issue
with this, if I don't find a sponsor and I just keep using my packages myself,
it's just the same work for me. If you like to give out funny advice, please
do so, people are doing everywhere on the net. But don't expect anyone to join
debian just to do the odd jobs and wanting to be "a slave to Debian". And
don't think that telling people "the contribution you want to offer is not
needed, please do the stuff we don't like" is a successful way of getting
anywhere.

Again, please don't take offence, I don't mind your answer in itself, I just
want to point out some issues with the impression that potential volunteers
get when considering to apply for debian membership.

Cheers

Thomas

Re: How to be a great Debian Developer

[Russell Coker]

On Tue, 28 Jan 2003 08:55, Thomas Viehmann wrote:
> still left, but you should well know that a volunteer project needs to
> distribute the dull jobs amongst those that are working for the main cause.

That is a fair point.  However you may have noticed that there are 
difficulties in becoming a new Debian developer.  Doing some of the dull jobs 
may make that easier for you.

> In addition, "helping out maintainers" is something that strongly depends
> on the willingness of maintainers to accept help. In my experience, the
> quality of the packages is strongly correlated (maybe even causal, not
> coincidental) to the willingness of maintainers to accept help and user
> comments and their friendlyness to answer questions.

That is true to a certain extent.  However there are some packages that are so 
difficult to maintain that even with a lot of help and a lot of hard work 
there will still be plenty of bugs left to fix.  Glibc and X spring to mind.

> Again, please don't take offence, I don't mind your answer in itself, I
> just want to point out some issues with the impression that potential
> volunteers get when considering to apply for debian membership.

To a large extent the Debian developers don't have direct control over this 
anyway.  Search the archives and you'll find plenty of flame-wars on this 
topic.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

How to debug apt-get dependencies

[Karolina Lindqvist]

The subject line says it all. I have a condition where apt-get refuses to 
upgrade. How can I figure out exactly what apt-get does not like:

Here follows my example run. The reason I use a versioned install is just 
because otherwise apt-get just refuses to consider the upgrade. This is a 
problem I have gotten before and found it quite hard to figure out the 
reason, and is never sure if I really got the right solution. There must be a 
way to figure out exactly what goes wrong.

First:
shakti:~# dpkg --compare-versions '4:3.1.0++kl-1' '>' '4:3.1.0+rc6+kl-3'; echo 
"$?"
0

Ok, version 4:3.1.0++kl-1 is the greater version.
Now:

shakti:~# apt-get install -t unstable libkdecore4
Reading Package Lists... Done
Building Dependency Tree... Done
Sorry, libkdecore4 is already the newest version.
Done
0 packages upgraded, 0 newly installed, 0 to remove and 58  not upgraded.

Ooops. already the newest version?
But what about the following, and the compare-version above:

shakti:~# apt-cache show libkdecore4 | grep Version
Version: 4:3.1.0++kl-1
Version: 4:3.1.0+rc6+kl-3
shakti:~#

Let's try this:

shakti:~# apt-get install -t unstable libkdecore4=4:3.1.0++kl-1

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

Sorry, but the following packages have unmet dependencies:
  libkdecore4: Depends: libdcop4 (>= 4:3.1.0++kl) but 4:3.1.0+rc6+kl-3 is to 
be installed
   Depends: libkdefx4 (>= 4:3.1.0++kl) but 4:3.1.0+rc6+kl-3 is to 
be installed
   Depends: kdeinit4 (= 4:3.1.0++kl-1) but 4:3.1.0+rc6+kl-3 is to 
be installed
   Depends: libkdecore-data but it is not going to be installed
E: Sorry, broken packages

Note here that all those missing packages are existing, and according to the 
dpkg compare-version above, have higher version numbers. apt-get is doing the 
wrong thing above. Why is it not updating those packages shown, libdcop4, 
libkdefx4 and kdeinit4, when there are newer version available that will 
satisfy the dependencies?

the full output of the run follows in the end


Karolina


shakti:~# apt-get install -t unstable libkdecore4=4:3.1.0++kl-1
Reading Package Lists... Done
Building Dependency Tree... Done
Starting
Starting 2
Investigating libkdecore4
Package libkdecore4 has broken dep on libdcop4
  Considering libdcop4 2082 as a solution to libkdecore4 11796
Package libkdecore4 has broken dep on libkdefx4
  Considering libkdefx4 2079 as a solution to libkdecore4 11796
Package libkdecore4 has broken dep on kdeinit4
  Considering kdeinit4 1024 as a solution to libkdecore4 11796
Investigating libkdecore-data
Package libkdecore-data has broken dep on libkdecore4
  Considering libkdecore4 11796 as a solution to libkdecore-data 285
  Removing libkdecore-data rather than change libkdecore4
Investigating kdelibs4
Package kdelibs4 has broken dep on libkdecore4
  Considering libkdecore4 11796 as a solution to kdelibs4 3
  Removing kdelibs4 rather than change libkdecore4
Investigating kdelibs-dev
Package kdelibs-dev has broken dep on libkdecore4
  Considering libkdecore4 11796 as a solution to kdelibs-dev 3
  Removing kdelibs-dev rather than change libkdecore4
Investigating ksms
Package ksms has broken dep on kdelibs4
  Considering kdelibs4 3 as a solution to ksms 0
  Removing ksms rather than change kdelibs4
Investigating kio-locate
Package kio-locate has broken dep on kdelibs4
  Considering kdelibs4 3 as a solution to kio-locate 0
  Removing kio-locate rather than change kdelibs4
Investigating libkdegames-dev
Package libkdegames-dev has broken dep on kdelibs-dev
  Considering kdelibs-dev 3 as a solution to libkdegames-dev 0
  Removing libkdegames-dev rather than change kdelibs-dev
Investigating libkscan-dev
Package libkscan-dev has broken dep on kdelibs-dev
  Considering kdelibs-dev 3 as a solution to libkscan-dev 0
  Removing libkscan-dev rather than change kdelibs-dev
Investigating kickpim
Package kickpim has broken dep on kdelibs4
  Considering kdelibs4 3 as a solution to kickpim 0
  Removing kickpim rather than change kdelibs4
Investigating koffice-dev
Package koffice-dev has broken dep on kdelibs-dev
  Considering kdelibs-dev 3 as a solution to koffice-dev 0
  Removing koffice-dev rather than change kdelibs-dev
Investigating libkdecore4
Package libkdecore4 has broken dep on libdcop4
  Considering libdcop4 2082 as a solution to libkdecore4 11796
Package libkdecore4 has broken dep on libkdefx4
  Considering libkdefx4 2079 as a solution to libkdecore4 11796
Package libkdecore4 has broken dep on kdeinit4
  Considering kdeinit4 1024 as a solution to libkdecore4 11796
Package libk

Re: How to be a great Debian Developer

[Chad Miller]

Hi, Thomas.

On Tue, Jan 28, 2003 at 08:55:32AM +0100, Thomas Viehmann wrote:
> Taking your answer literally, the conclusion is that you think that debian
> has enough package maintainers and the others should bother about the crums
> that fall from the table that existing DDs are not interested in.

I don't think Debian is necessarily better off for gaining more main-
tainers.  More maintainers who are productive are great, but maintaining
a package currently means that no one else maintains it (6-month waits
and NMUs aside), and that one person "owning" a package and poorly
packaging it or neglecting it means that a package that is potentially
very useful is useless.

Unfortunately, it's hard to tell who is serious about Debian and who is, 
for instance, likely to do work for a month, decide RedHat is what they
want to run at home, and never be seen again.  

A long NM process used to weed out people joining Debian on a whim
(good), but it also weeded out good developers with a low tolerance for
bureaucracy (very, very bad).  Now that it's relatively simple again, I
thought I'd send a cautionary note to new maintainers, asking them to
consider carefully why they're applying.

There _is_ more to do than "crumb"-work, but everyone has to do the work
that is no fun at all, too.  When newbies realize this, they're not as
likely to stick around.

>[...]
> I've thought about packaging quite a few things before, but now I think I've
> found something truely worthwhile.

That's great.  If you want to maintain it yourself, then welcome to
Debian!

> Why would you expect anyone to write the manpages the package maintainer
> doesn't bother about? True, there are those maintainers that don't have the
> time because they're doing very much for the project, but for the most part,
> I cannot help but think that they just don't care. I did write two manpages
> for my own package because that is the lintian warning that's still left, but
> you should well know that a volunteer project needs to distribute the dull
> jobs amongst those that are working for the main cause.

No it's not fun work, but someone has to do it.  I'm not claiming that
all current maintainers do things correctly -- quite the opposite.

(Some people in Debian suggest that N months of that sort of work should
be a prerequisite for getting the ability to upload new packages.  It's 
informal grumbling, so don't expect it in the NM rules soon.)

I was pointing out that there are ways to help Debian for which one
doesn't have to go through NM.  

> With wnpp matters are even worse, because for the most part, they are just
> "ugly, pointless packages noone in the world would care about". (There are
> notable exceptions every once in a while, but mostly this is the exact reason
> they're abandoned in the first place.)

This is true.  A significant fraction of the packages you see are the
tangible results of Joe Debian packaging his own software.  

More software authors filing RFP bugs instead of NM applications would
help.  The request/claim buffer of WNPP would keep out a lot of "useless"
stuff.
 
> In addition, "helping out maintainers" is something that strongly depends on
> the willingness of maintainers to accept help. In my experience, the quality
> of the packages is strongly correlated (maybe even causal, not coincidental)
> to the willingness of maintainers to accept help and user comments and their
> friendlyness to answer questions. 

Yes, and if you're on debian-mentor, you're probably a personality that
doesn't mind getting help, so I have nothing to add here.
 
>Let's face it, the main cause of problems 
> in
> debian are the problems of and with the present developers and do not relate
> very well to future developers.

I've said "these are the problems."   Will readers of this contribute to
the problems or help reduce them?

>[...]   Don't expect anyone to join
> debian just to do the odd jobs and wanting to be "a slave to Debian". And
> don't think that telling people "the contribution you want to offer is not
> needed, please do the stuff we don't like" is a successful way of getting
> anywhere.

I guess that depends on what I consider "success".

I don't want to send away good developers, but in my estimation when
four people join, the first is productive, the second is an obstacle, and
the third and forth (who could have been productive) are stuck cleaning
up after the second.

I really want a way to avoid #2.  I fear there isn't one, though.

- chad

Re: OpenEXR beta packages.

[Andrew Lau]

On Mon, Jan 27, 2003 at 04:30:32PM +0100, Jesus Climent wrote:
> They are lintian clean, but linda reports an odd error.

Let me guess,

[EMAIL PROTECTED]:/usr/src/debian-devel/active% linda -i
libopenexr0_1.0.4-1_i386.deb
X: libopenexr0; Package name doesn't contain one of the SONAMEs.
 This package isn't named after one of the SONAMEs of the shared
 library, or the SONAME has changed and the package name hasn't.

I talked to StevenK about this and he pointed out that it may be a
Linda bug. X is for experimental after all. My guess is because
libopenexr0 does not contain a libopenexr.so.0 file as such.

> I had a bit of troubles tracking down to bugs already reported to
> upstream:
> * -O2 code cannot be compiled using gcc3.2.

I had no such problem here.

> * exrdisplay segfaults if there are no type1 fonts installed.

Haven't tested this one yet.

> If you manage to find a better solution, please report it.

I already had most of my OpenEXR packages completed before I find out
about your ITP and going through your .diff.gz now, it seems like you
could do with a lot more polishing and some experince.

* Real minor, but why 1.0.4-2 and not -1? Debian doesn't have any
  OpenEXR packages already.

* Upstream's orig tarball contained no config.guess or config.sub, so
  your patch should not include them.

* Remove all those sample and unneccesary debhelper files such as all
  the dirs files and postinst.

* Clean up those commented commands in debian/rules. The aim is to
  keep the diff.gz as small and clean as possbile. It's also better to
  use dh_install instead of dh_movefiles

* Your manpage could at least describe how to use
  exrdisplay.  What you have now is
  plain laziness = P

* HTML should go into /usr/share/package/doc/HTML/. I don't think
  they're getting installed anyway since you only have debian/doc and
  not debian/exrdisplay.doc

* Read Junichi Uekawa's Debian Library Packaging guide carefully!
  http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

Did you pick the name libopenexr1 randomly? The SONAME on
those libs was 0 as far as I could tell!

Call the package libopenexr0-dev as well, and
Provides/Replaces libopenexr-dev as Junichi recommends.

* libopenexr0-dev should Depends: libopenexr0 (= ${Source-Version}),
  xlibmesa-gl-dev, xlibmesa-glu-dev. "grep #include
  /usr/include/OpenEXR/*" to see why.

Please fix all of this as soon as possible. Sorry if I sound
impatient, but I really need to get OpenEXR support into my Film Gimp
0.15-1 packages, and I won't hesitate to upload my packages instead if
I have to. However, I am willing to help you improve (or even
co-maintain) your next batch of OpenEXR packages.

Cheers,
Andrew "Netsnipe" Lau

--
---
* Andrew "Netsnipe" Lau  Computer Science & Student Rep, UNSW *
*   # apt-get into it Debian GNU/Linux Package Maintainer *
**
* GnuPG 1024D/2E8B68BD 0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D 2E8B 68BD *
---



pgp3AY73ROK2q.pgp
Description: PGP signature

RE: How to be a great Debian Developer

[deFreese, Barry]

>[...]   Don't expect anyone to
join
> debian just to do the odd jobs and wanting to be "a slave to Debian". And
> don't think that telling people "the contribution you want to offer is not
> needed, please do the stuff we don't like" is a successful way of getting
> anywhere.

>-Original Message-
>From: Chad Miller [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, January 28, 2003 7:11 AM
>To: Thomas Viehmann
>Cc: debian-mentors
>Subject: Re: How to be a great Debian Developer
>
>I guess that depends on what I consider "success".
>
>I don't want to send away good developers, but in my estimation when
>four people join, the first is productive, the second is an obstacle, and
>the third and forth (who could have been productive) are stuck cleaning
>up after the second.
>
>I really want a way to avoid #2.  I fear there isn't one, though.
>
>   - chad


Hey I've offer to be a "slave" to Debian but no one seems to be taking me
seriously.  I'll write man pages, clean up code, test, whatever, I just need
some guidance in the right direction.  The way I look at it, the more
exposure I get, the more I learn.  The more I learn through doing the grunt
work then maybe I get better can move to more of a developer and then
someone else can pick up the grunt work.

Barry deFreese
NTS Technology Services Manager
Nike Team Sports
(949)-616-4005
[EMAIL PROTECTED]

"Technology doesn't make you less stupid; it just makes you stupid faster."
Jerry Gregoire - Former CIO at Dell

Re: How to be a great Debian Developer

[Tom Marshall]

> Unfortunately, it's hard to tell who is serious about Debian and who is, 
> for instance, likely to do work for a month, decide RedHat is what they
> want to run at home, and never be seen again.  
> 
> A long NM process used to weed out people joining Debian on a whim
> (good), but it also weeded out good developers with a low tolerance for
> bureaucracy (very, very bad).  Now that it's relatively simple again, I
> thought I'd send a cautionary note to new maintainers, asking them to
> consider carefully why they're applying.

I sent a message to -devel on this subject some four weeks ago.  Please see:

http://lists.debian.org/debian-devel/2003/debian-devel-200301/msg00125.html

The bottom line is that I'm most concerned with the unbounded wait times
(I suppose that puts me in your latter category).  I would not mind waiting
a few months if I knew that the process could not take any longer than, say,
6 months.  I'm not anxious to apply when there are people who have been
waiting for over a year with no indication of when they may be accepted or
rejected.  That's not just bureaucracy, it borders on cruelty.

The thread referenced above seems to have died and I haven't heard anything
on the subject in a couple of weeks, even though (it appears) most people
are sympathetic.  I'm sticking around for a little while, just in case, but
I am rapidly coming to the conclusion that I should let an existing DD
package my app and be done with it.  :-/

-- 
"... developing software for Microsoft [Windows] is like brushing the teeth
of a Great White Shark with a piece of raw steak."
-- Robert G. Brown, LinuxToday


pgp45u13uDntJ.pgp
Description: PGP signature

Re: How to be a great Debian Developer

[Stephen Gran]

This one time, at band camp, deFreese, Barry said:
> Hey I've offer to be a "slave" to Debian but no one seems to be taking
> me seriously.  I'll write man pages, clean up code, test, whatever, I
> just need some guidance in the right direction.  The way I look at it,
> the more exposure I get, the more I learn.  The more I learn through
> doing the grunt work then maybe I get better can move to more of a
> developer and then someone else can pick up the grunt work.

Check out
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=wnpp&archive=no
for a list of packages that are requested, orphaned, or otherwise
need some help to get into the archive.

http://www.debian.org/Bugs/pseudo-packages
for a list of other so-called pseudo packages (things like the mailing
lists, or the boot cd's) and a list of unresolved bugs on them.  Some of
these need quite a bit of work (like the boot cd's) from what I
understand, so help there might be appreciated.

That's at least a start.  I'm sure there must be a way to get a list of
bugs with a specific tag; e.g 'help' or 'unreproducable' that need some
help to fix, but I can't find it right now.  Colin, is that possible?

-- 
 --
|  Stephen Gran  | The problem with the gene pool is that  |
|  [EMAIL PROTECTED] | there is no lifeguard.  |
|  http://www.lobefin.net/~steve | |
 --


pgpaJjcgHDjpk.pgp
Description: PGP signature

Re: How to be a great Debian Developer

[Russell Coker]

On Tue, 28 Jan 2003 17:55, deFreese, Barry wrote:
> Hey I've offer to be a "slave" to Debian but no one seems to be taking me
> seriously.  I'll write man pages, clean up code, test, whatever, I just

One thing you could do is write a script that searches for a man page for 
every binary on your system.  /usr/bin and /bin binaries deserve man pages in 
section 1, /usr/sbin and /sbin binaries deserve man pages in section 8.  If 
you write a Perl script to search for such man pages you will should find 
hundreds of them to be missing on a typical system (there's more than a few 
missing from my packages).  Then start writing some man pages!

Also publish the script, I'm sure other people would find it useful.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: How to be a great Debian Developer

[Colin Watson]

On Tue, Jan 28, 2003 at 01:03:11PM -0500, Stephen Gran wrote:
> That's at least a start.  I'm sure there must be a way to get a list of
> bugs with a specific tag; e.g 'help' or 'unreproducable' that need some
> help to fix, but I can't find it right now.  Colin, is that possible?

Not for tags in general, but lists for 'help', 'security', and
'unreproducible' are linked off http://qa.debian.org/ (the third set of
links under "Work needed").

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: How to be a great Debian Developer

[Bas Zoetekouw]

Hi Russell!

You wrote:

> One thing you could do is write a script that searches for a man page for 
> every binary on your system.  /usr/bin and /bin binaries deserve man pages in 
> section 1, /usr/sbin and /sbin binaries deserve man pages in section 8.  If 
> you write a Perl script to search for such man pages you will should find 
> hundreds of them to be missing on a typical system (there's more than a few 
> missing from my packages).  Then start writing some man pages!

There is already such a script, see http://qa.debian.org/man-pages.html

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 

RE: How to be a great Debian Developer

[deFreese, Barry]

Bas,

I've looked at this page and had a brief discussion with Bastian on it.  I'm
somewhat of a noob to Linux and really green on the development side so my
question was.  How do I know if any of these packages listed on this page
are even still in use?  Many of the bug reports for a lot of these packages
are well over a year old.  Also, I need to start on some that are a little
smaller to align with my current skills (or lack thereof) to get started.
Any suggestions?

Thanks!!

Barry deFreese
NTS Technology Services Manager
Nike Team Sports
(949)-616-4005
[EMAIL PROTECTED]

"Technology doesn't make you less stupid; it just makes you stupid faster."
Jerry Gregoire - Former CIO at Dell



-Original Message-
From: Bas Zoetekouw [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 28, 2003 11:35 AM
To: Russell Coker
Cc: deFreese, Barry; 'debian-mentors@lists.debian.org'
Subject: Re: How to be a great Debian Developer


Hi Russell!

You wrote:

> One thing you could do is write a script that searches for a man page for 
> every binary on your system.  /usr/bin and /bin binaries deserve man pages
in 
> section 1, /usr/sbin and /sbin binaries deserve man pages in section 8.
If 
> you write a Perl script to search for such man pages you will should find 
> hundreds of them to be missing on a typical system (there's more than a
few 
> missing from my packages).  Then start writing some man pages!

There is already such a script, see http://qa.debian.org/man-pages.html

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 

Question about lintian's shell-script-fails-syntax-check

[Marco Kuhlmann]

Hi all.

A package of mine, mozart, uses some rather informal shell scripts.  The
idea is to provide a wrapper around one of their tools, ozengine -- the
shell script passes its arguments and a kind of initialisation code to
ozengine.  To illustrate this, the beginning of one script looks like
follows:

#!/bin/sh
exec ozengine $0 "$@"
^B^B^B^K^?<83>?^_<8B>[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL 
PROTECTED]@^C<9D>}^G|TU;<9E><97>

So from the third line on, each of these shell scripts is syntax error. :-)
Since recently, lintian takes offence in such syntax errors.  What am I
supposed to do?  The scripts seem to work fine in spite of their syntax
errors, but I am not sure how to convince lintian about that.

Thanks for any advice,
Marco


pgpVzdAHgdFPz.pgp
Description: PGP signature

joining Debian / packaging buildd

[Jeremy Lainé]

Hi!

I am interested in becoming a Debian developer and have already
produced a number of Debian packages, but they fall in the "pet
packages" category referred to in another thread on this list. The
most recent ones are mpf70-source and mpf70-utils, respectively the
source for a kernel module (builds with make-kpkg) and some userspace
utilities for the MPman MP-F70 portable MP3 player:

deb http://dev.jerryweb.org/debian ./ 
deb-src http://dev.jerryweb.org/debian ./ 

As far as I can tell, these packages are pretty much ready, but I am
putting them on hold until someone else expresses interest in them, so
as not to clutter the Debian archive pointlessly.

In the meantime, I think I've found something to sink my teeth in,
namely packaging buildd. I realise it's a big bugger, but as packaging
it seems to have been on the TODO list for a while I suppose any work
I put into it is that much done.. I am looking for a contact from the
buildd team to ask whether I can rename some files, or whether this is
not a purely Debian package and needs to be handled like a package
with an upstream and a Debian diff.

Jeremy

--  
http://www.jerryweb.org/ : JerryWeb.org
http://sailcut.sourceforge.net/  : Sailcut CAD
http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux

Re: OpenEXR beta packages.

[Michel Dänzer]

On Die, 2003-01-28 at 17:35, Andrew Lau wrote:

> * libopenexr0-dev should Depends: libopenexr0 (= ${Source-Version}),
>   xlibmesa-gl-dev, xlibmesa-glu-dev. "grep #include
>   /usr/include/OpenEXR/*" to see why.

You probably mean libgl-dev and libglu-dev instead of xlibmesa-gl-dev
and xlibmesa-glu-dev?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Re: Question about lintian's shell-script-fails-syntax-check

[Bastian Kleineidam]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marco,

On Tue, Jan 28, 2003 at 09:39:15PM +0100, Marco Kuhlmann wrote:
> The scripts seem to work fine in spite of their syntax
> errors, but I am not sure how to convince lintian about that.
Read file:///usr/share/doc/lintian/lintian.html/ch2.html#s2.4
for lintian overrides.


Cheers, Bastian
- -- 
 Bastian Kleineidam

 Atombombe · Plutonium · Fat Man · Do it Yourself · Tim Taylor
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Nvt4eBwlBDLsbz4RAh2jAJ0QSg3DHTDfTR+jcpPU4bWhm1wQ9QCZAbiI
H2vDo/WygF0alSZcfGhBdas=
=mWrO
-END PGP SIGNATURE-

Re: joining Debian / packaging buildd

[Roger Leigh]

Jeremy Lainé <[EMAIL PROTECTED]> writes:

> In the meantime, I think I've found something to sink my teeth in,
> namely packaging buildd. I realise it's a big bugger, but as packaging
> it seems to have been on the TODO list for a while I suppose any work
> I put into it is that much done..

You might be interested in

http://www.whinlatter.uklinux.net/buildd/

This doesn't yet automate all of the setup properly, and is a bit out
of date with my local CVS, but does work with a bit of manual setup
after installation.

> I am looking for a contact from the buildd team to ask whether I can
> rename some files, or whether this is not a purely Debian package
> and needs to be handled like a package with an upstream and a Debian
> diff.

You should probably subscribe to buildd-discuss at nocrew.org.


Regards,
Roger

-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers

Mathwar - Orphaned Package

[David Lloyd]

Hi There,

* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174700

A few really silly questions:

1) Is that package still orphaned?
 - I'd say so because upstream has gone to version 0.2.X

2) I want to adopt it
 - upstream author is happy
 - haven't heard from the maintainer Peter Crystal <[EMAIL PROTECTED]>
   but in absence of correspondence I'm assuming this is still the case

..but I can't work out HOW to do the part that says "Change the O: to
ITA:".

*or* for that matter what to do now.

<-- can someone point me at a newbie guide to sort of adopting an orphaned
packages :0?


dsl
-- 
Microbits Linux Technician

Ph: +61 8 8362 9220

Re: Question about lintian's shell-script-fails-syntax-check

[Sean 'Shaleh' Perry]

On Tuesday 28 January 2003 13:51, Bastian Kleineidam wrote:
> Marco,
>
> On Tue, Jan 28, 2003 at 09:39:15PM +0100, Marco Kuhlmann wrote:
> > The scripts seem to work fine in spite of their syntax
> > errors, but I am not sure how to convince lintian about that.
>
> Read file:///usr/share/doc/lintian/lintian.html/ch2.html#s2.4
> for lintian overrides.
>
>
> Cheers, Bastian

or perhaps come up with some logic to detect this kind of odd shell script.

Re: Mathwar - Orphaned Package

[Joe Nahmias]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David,

> 1) Is that package still orphaned?
>  - I'd say so because upstream has gone to version 0.2.X
No new information has been sent to the bug since the original report,
and the title still says "O:", so I'd say it is orphaned.

> ..but I can't work out HOW to do the part that says "Change the O: to
> ITA:".
Send a message to [EMAIL PROTECTED], containing something like:
retitle 174700 ITA: mathwar -- A flash card game designed to teach maths.
See  for more info on how to
use [EMAIL PROTECTED]

> *or* for that matter what to do now.
Fix the outstanding bugs (if any), update the package to the latest
upstream version, upload the package with yourself as maintainer
(closing the bug in the process).

> <-- can someone point me at a newbie guide to sort of adopting an orphaned
> packages :0?
See, for example, , especially the
information at the end.

Hope this helps!

Joe Nahmias, DD wannabe :-)
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE+N1t/Kl23+OYWEqURAnWLAKCGZOE5vVpCCr7La/ZAXTPLcvXgVACfetjf
ZBi2yoCN8hChaqtn/Vd39Ok=
=20Re
-END PGP SIGNATURE-