sponsor quake3 quake3-data packages

[Marc Leeman]

Hi,

I've been maintaining a number of packages for about 5 years. For these
packages, I've been working with a number of DDs and since the
cooperation was so satisfactory, I never had the need (and for a couple
of years, the time) to apply for DD myself.

Last week, I made packages for Quake III. For these, I used the work
great of Jamie, the quake II maintainer and adjusted it: the package is
split in quake3 and quake3-data.

As such, I am interested in a sponsor to upload these packages and have
a look at them. The quake3 package is fine (IMHO), but I need to have
another look at the quake3-data package, though it is already functional
for installing wrt the demo and the official game. Yeah, I have to add a
manpage for the quake3 binary, just sprung into mind.

I plan to add support for Team Arena, but since that add-on has only
been released as a windows installable (that can be handled with wine);
I don't think that extracting can be handled with the installer itself.

Anyone intersted in answering the call?

-- 
  greetz, marc
My progeny were tiny. Tiny and handsome, like their father.
Rygel - The Hidden Memory
scorpius.homelinux.org 2.6.13.2 #1 Fri Sep 23 07:23:21 CEST 2005 GNU/Linux


signature.asc
Description: Digital signature

Re: How to add applications to IceWM menu

[Jan Wagemakers]

Stan Vasilyev <[EMAIL PROTECTED]> schreef:

> How do I add an application to IceWM menu without manually editing
> /etc/X11/icewm/menu file?

Maybe  and
 is what you are looking
for? 


-- 
Met vriendelijke groetjes - Jan Wagemakers -

... My home build PIC18f452(4Mhz) Embedded Web Server...



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

RFS: rkward

[Thomas Friedrichsmeier]

Dear debian mentors,

I have made another attempt at creating a debian package for rkward, a 
scientific KDE application I develop. Naturally, I would like to get this app 
into the main debian archive.
Could somebody please sponsor me an upload, and/or help me fix up the package 
to meet the criteria for inclusion into debian?

Package description:
Description: A KDE frontend to the R statistics language
 RKWard is meant to become an easy to use, transparent frontend to the 
R-language, a very powerful, yet hard-to-get-into scripting-language with a 
strong focus on statistic functions. It will not only provide a convenient 
user-interface, however, but also take care of seamless integration with an 
office-suite. Practical statistics is not just about calculating, after all, 
but also about documenting and ultimately publishing the results.
 RKWard is still in development status. Right now it is most useful as an IDE 
to users with some experience in R, or willing to learn R.

Homepage: http://rkward.sourceforge.net
Downloads: http://sourceforge.net/project/showfiles.php?group_id=50231
CVS instructions: http://sourceforge.net/cvs/?group_id=50231

Current debian package available at: http://rkward.sourceforge.net/debian
ITP-bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=92

Thanks!
Thomas Friedrichsmeier


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

Re: RFS: rkward

[Steffen Joeris]

Hi

I am not yet a DD so I can't sponsor your package sorry.
But maybe I can give you some advice for improving the packaging.

OK there are some issues:

1. Well you provide a native debian package as I can see.
 I don't think that your package should be a native one, although you are the 
upstream. You package can be used in various distributions (of course also in 
Debian) so it would be a non-native package.
I think you are providing a Debian directory in the upstream version.
Think about that point and maybe delete the debian-dir for the official 
version and during the debianization you can create the debian-dir.
Then please make sure that the diff (which will be created during the build of 
a non-native package) includes only the debian-dir.

2. I think you don't need libqt3-mt-dev as a build-depends, because 
kdelibs4-dev depends against libqt3-mt-dev. I haven't checked the other 
build-depends.

3. In the control file you should improve the layout of the description (have 
a look at other debian packages).

4. The short description shouldn't contain of big letters (because the short 
description is not a full sentence).

5. The changelog entry should close the ITP report.

6. The current standards version is 3.6.2

7. You don't need usr/sbin in the dirs.

8. There is a rpath (as lintian told me). See the lintian warning:
W: rkward: 
binary-or-shlib-defines-rpath ./usr/bin/rkward 
/usr/lib:/usr/share/qt3/lib:/usr/X11R6/lib:/usr/lib/R/lib/

I think you can directly fix it (upstream) ;)

BTW you can run lintian *.deb to see if there are problems with your package 
(do debuild and it is done automatically :) ).

For more information use lintian -i

9. A manpage is missing ;)

10. The package contains CVS-dirs, I think you should remove them.

Now I stop checking here, because I am right busy, sorry. Please fix these 
issues (or what till someone told me that I am wrong ;) ) and then write a 
mail.
Anyway thank you for your contribution to Debian and for your software, you 
are always welcome.

Greetings
Steffen


pgp3WuqRtL2Ka.pgp
Description: PGP signature

Re: RFS: irmp3 -- mp3 Jukebox (LIRC support)

[Erik Schanze]

Hi Mario,

please send your answers on my list mails back to the list, so others 
can also help or could correct me, if I'm wrong.

Mario Iseli Mario Iseli <[EMAIL PROTECTED]>:
> On Sun, 2005-11-06 at 16:42 +0100, Erik Schanze wrote:
> > Perhaps you should mention, that irmp3 was recently removed from
> > archive because
> > it was unmaintained for a long time[1].
> >
> > If irmp3 enters archive again, you have to deal with some old
> > bugs[2], some of them
> > were RC bugs.
>
> Yes, i saw it. To the bugs: I had a look at it and had contact with
> the upstream - it is no problem anymore, everything is solved.
>
Every single bug is solved? Great. 
So you could add a note to changelog that state this and "Closes:" all 
bugs.
This seems silly, because they are already closed, but leave IMO a good 
closing report on archived bugs.

> > Anyway let me do some remarks on your package:
> >
> > debian/control:
> > - You Build-Depend on autotools-dev, but your diff.gz contains
> >   config.guess.diff and config.sub.diff. It's better to backup the
> >   original files before configure and link to
> > /usr/share/misc/config.* then restore it on clean. So you will get
> > a smaller diff.gz. (same applied to irmp3-ncurses)
>
> Why do you mean? A friend of me (an expierienced maintainer) told me
> that this is okey. He had already a look on my package.
>
Your way will not fail, but could be improved.
The advantage of Build-Depends on autotools-dev is to have the newest 
config.* stuff available. There is no need to include the new config.* 
files into diff. If you do so, you don't need to Build-Depend on 
autotools-dev, but your diff grows. Yours is actually 29208 byte.

If you use a target before configure to backup original config.* files 
(if were are any) and link to the autotools-dev ones, and commands in 
clean to remove the links and restore original config.* files.
See the rules file on
http://www.erikschanze.de/debian/rules
(Don't forget to remove the created links 
by your rules file in upstream dir, if you test it.)

The resulting diff.gz will be 7694 Byte. :-)

> > debian/patches/01-manpages.dpatch:
> > - you change Jérémy to Jeremy, perhaps he will be unhappy about it.
> > Please see
> >   groff_char(7) for better substitution.
>
> In the original it is Jérémy, yes. But lintian is not happy with it
> and i had to change it!
>
Did you read groff_char(7)?
How about \['e]? I changed manpage.dpatch, see:
http://www.erikschanze.de/debian/01-manpages.dpatch
I also removed mail address from .TH line in irmp3d.7 because it is too 
long and overwrites version number in manpage footer.

> The updated can be found on the old location:
> http://server01.marioiseli.com/~mario/dpkgs/irmp3/
>
I had a look at it.
debian/rules:
- you gives the configure call a CFLAG with "-O2", but configure.in 
  defines "-O3", so gcc is called with -O2 -O3
  Because -Wall is also set, you should remove your CFLAG variable

debian/control:
- add a empty line (space and dot) between description and "Homepage:".

debian/docs:
- NEWS file is quite seemless, remove it

debian/copyright:
- Copyright Holder(s) -> Copyright Holders

manpages:
- You should rephrase irmp3conf.1. (e.g. option -f is very unclear to 
  me, too many defaults ;-).) 

- irmp3.conf.5:
  mouse_move_[left|right|up|downe] must be:
  mouse_move_[left|right|up|down]

- irmp3.conf.5, irmp3d.8:
  SEE ALSO: irmp3d_commands(1)
  This manpage doesn't exist.

The other manpages should also checked for technical errors and for 
wording, they sounds pretty strange sometimes.

Because I'm not a DD (yet), I'm unfortunately not able to sponsor yur 
packages, but hope my comments help you.


Kindly regards,
Erik


-- 
 www.ErikSchanze.de *
 Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
COMTEC in Dresden, 09. - 11. November 2005  *
  Info: http://www.messe-comtec.de/ *


pgpGAMqEckrbq.pgp
Description: PGP signature

Re: RFS: statist - Small and fast terminal-based statistics program

[Nico Golde]

Hi,
* Jakson A. Aquino <[EMAIL PROTECTED]> [2005-11-09 17:43]:
> I'm sorry for still using the wrong FSF address. Now it's
> really fixed. The new links are:
> 
> http://wald.intevation.org/frs/download.php/43/statist_1.3.1-1.diff.gz
> http://wald.intevation.org/frs/download.php/44/statist_1.3.1-1.dsc
> 
> Many thanks,

Ok here are the comments:
 - changelog file will not close an ITP
 - add one space before the Homepage tag in control (like 
   described in developers reference)
 - consider to add Upstream Author tag to copyright with 
   email addresses of them (not a bug)
 - delete unneeded comments in rules (sample file etc.)
 - the website in the readme is not the same as in control 
   and copyright
 - is dh_fixperms really needed?
 - dh_installexamples is not needed
 -  lintian -I ../*.changes
I: statist: hyphen-used-as-minus-sign usr/share/man/man1/statist.1.gz:7
I: statist: hyphen-used-as-minus-sign usr/share/man/man1/statist.1.gz:8
I: statist: hyphen-used-as-minus-sign usr/share/man/man1/statist.1.gz:64
(not a real problem, consider repoting it to upstream)

I think besides the first one this things should not prohibit an upload
but it would be nice if you can fix them.
Like I told in PM I am not yet a DD so I can not sponsor your package but it
would be nice if someone else could do it, its a cool tool.
Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org
Forget about that mouse with 3/4/5 buttons -
gimme a keyboard with 103/104/105 keys!


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

Re: RFS: rkward

[Thomas Friedrichsmeier]

Hi,

> I am not yet a DD so I can't sponsor your package sorry.
> But maybe I can give you some advice for improving the packaging.

Thanks very much for your advice. I'll work on those areas. A few questions:

> 1. Well you provide a native debian package as I can see.
>  I don't think that your package should be a native one, although you are
> the upstream. You package can be used in various distributions (of course
> also in Debian) so it would be a non-native package.
> I think you are providing a Debian directory in the upstream version.
> Think about that point and maybe delete the debian-dir for the official
> version and during the debianization you can create the debian-dir.
> Then please make sure that the diff (which will be created during the build
> of a non-native package) includes only the debian-dir.

I'll have to take your word on this, as I don't really understand the 
implicatons. Could somebody point me to some relevant FAQ/docs on this? 
Having this dir in the main distribution seemed to be the most convenient 
approach to building the package, and in fact, some users have used this to 
build their own packages for KUbuntu, or debian testing.

> 5. The changelog entry should close the ITP report.

What would be the correct way to do this? As far as I understand, a "Closes" 
should be attached to a change-entry. However the change in question would 
really be that somebody else uploads it. Is there a recommended way to do 
this?

> 8. There is a rpath (as lintian told me). See the lintian warning:
> W: rkward:
> binary-or-shlib-defines-rpath ./usr/bin/rkward
> /usr/lib:/usr/share/qt3/lib:/usr/X11R6/lib:/usr/lib/R/lib/
>
> I think you can directly fix it (upstream) ;)

Yeah, but I'll have to figure out how to do this, first. I hate those bloody 
makefiles...

Well, I suppose some of those issues mean I will have to wait until I release 
a new upstream version. I'll be back after that.

Thanks for your advice!
Thomas


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

Re: RFS: irmp3 -- mp3 Jukebox (LIRC support)

[Daniel Baumann]

Erik Schanze wrote:
> Your way will not fail, but could be improved.
> The advantage of Build-Depends on autotools-dev is to have the newest 
> config.* stuff available. There is no need to include the new config.* 
> files into diff. If you do so, you don't need to Build-Depend on 
> autotools-dev, but your diff grows.

Well, I beg to differ. Its important to have current config.{sub,guess}
to ensure, that the package builds on the latest debian ports (e.g.
kfreebsd), and sometimes.. if the files are really outdated, its even
essential to be buildable on !i386.

Second, to build-depend on autotools-dev and importing them via the
clean-target into the diff.gz. is the usual way to handle this.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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

Re: Package that depends on ming

[Joost van Baal]

Op di  8 nov 2005 om 09:28:37 -0500 schreef Alejandro Ríos P.:
> Hello.
> 
> I'm trying to package a program [1] that has a Perl server and a SWF
> client made with ming.

What's the name of the program?  What does it do?

> Since ming is not in Debian anymore,

You're talking about libming, which is still supported in woody
(oldstable).  Do you know why it didn't make it to sarge?  It might be
possible to get it re-enter Debian.  (Just saw upstream released 0.3.0,
which never was shipped with Debian.)

> should the
> package be on the non-free section? 

If it _depends_ upon libming, your program can't be shipped with Debian
as long as libming is not in Debian.


> [1]Files in http://icom.avatar.com.co/alerios/debian/

Bye,

Joost



signature.asc
Description: Digital signature

Re: RFS: rkward - rpath-problem

[Thomas Friedrichsmeier]

Hi again,

on more thing:

> > 8. There is a rpath (as lintian told me). See the lintian warning:
> > W: rkward:
> > binary-or-shlib-defines-rpath ./usr/bin/rkward
> > /usr/lib:/usr/share/qt3/lib:/usr/X11R6/lib:/usr/lib/R/lib/
> >
> > I think you can directly fix it (upstream) ;)
>
> Yeah, but I'll have to figure out how to do this, first. I hate those
> bloody makefiles...

Doing this was easier than expected. I just added --disable-rpath 
to ./configure and that did that. However then, it's not quite as easy after 
all: Now when trying to run I get:

rkward: error while loading shared libraries: libR.so: cannot open shared 
object file: No such file or directory

The problem is, I have to link against R, and libR.so is in a non-default 
location (/usr/lib/R/lib/libR.so), which obviously isn't in the library path. 
I don't think I can fix this inside the rkward-package, but rather the 
R-package would need adjusting (maybe a link in /usr/lib). What should I do, 
submit a bug-report for the R-package?

Thanks!
Thomas


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

Re: sponsor quake3 quake3-data packages

[Frank Lichtenheld]

On Wed, Nov 09, 2005 at 09:09:03AM +0100, Marc Leeman wrote:
> Anyone intersted in answering the call?

A link to actual packages files would be good...

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

essential vs. required vs. base

[Justin Pryzby]

Packages marked "Essential: yes" have to be operational before they
are configured, and packages need not (and should not) depend on them,
in the same was as they needn't and shouldn't to build-depend on
build-essential packages such as gcc and make.  Essential packages are
also the only ones which can be relied on to be working in
postrm:purge.

The priority system exists to help define dependencies .. packages
cannot depend on other packages with a lower priority.  Policy
indicates that "Priority: required" packages are thus marked because
they are (mostly) needed by dpkg, which seems like a fine criteria.

I'm including the context diff between essential packages and required
ones.  Since essential implies required, why isn't there simply
another priority class, instead of a separate "Essential" field??

There is also the independent concept of "base system", and I don't
understand how that fits in with either of the above.

-- 
Clear skies,
Justin

--- pkgs-essential  2005-11-07 15:32:12.0 -0500
+++ pkgs-required   2005-11-07 15:31:52.0 -0500
@@ -3,20 +3,58 @@
 bash
 bsdutils
 coreutils
+debconf
+debconf-i18n
 debianutils
 diff
 dpkg
+dselect
+e2fslibs
 e2fsprogs
 findutils
+gcc-4.0-base
 grep
 gzip
 hostname
+initscripts
+libacl1
+libattr1
+libblkid1
+libc6
+libcap1
+libcomerr2
+libdb3
+libdb4.3
+libgcc1
+liblocale-gettext-perl
+libncurses5
+libnewt0.51
+libpam-modules
+libpam-runtime
+libpam0g
+libselinux1
+libsepol1
+libslang2
+libss2
+libstdc++6
+libtext-charwidth-perl
+libtext-iconv-perl
+libtext-wrapi18n-perl
+libuuid1
 login
+lsb-base
+makedev
+mawk
 mount
 ncurses-base
 ncurses-bin
+passwd
 perl-base
+procps
 sed
+slang1a-utf8
+sysv-rc
 sysvinit
 tar
 util-linux
+zlib1g


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

Re: RFS: rkward - rpath-problem

[Justin Pryzby]

On Wed, Nov 09, 2005 at 09:21:10PM +0100, Thomas Friedrichsmeier wrote:
> > > 8. There is a rpath (as lintian told me). See the lintian warning:
> > > W: rkward:
> > > binary-or-shlib-defines-rpath ./usr/bin/rkward
> > > /usr/lib:/usr/share/qt3/lib:/usr/X11R6/lib:/usr/lib/R/lib/
> > >
> > > I think you can directly fix it (upstream) ;)
> >
> > Yeah, but I'll have to figure out how to do this, first. I hate those
> > bloody makefiles...
> 
> Doing this was easier than expected. I just added --disable-rpath 
> to ./configure and that did that. However then, it's not quite as easy after 
> all: Now when trying to run I get:
> 
> rkward: error while loading shared libraries: libR.so: cannot open shared 
> object file: No such file or directory
> 
> The problem is, I have to link against R, and libR.so is in a non-default 
> location (/usr/lib/R/lib/libR.so), which obviously isn't in the library path. 
> I don't think I can fix this inside the rkward-package, but rather the 
> R-package would need adjusting (maybe a link in /usr/lib). What should I do, 
> submit a bug-report for the R-package?
If the R libraries are intended to be useful to other packages, then
they should be in /usr/lib/, and not /usr/lib/R/.

But, if they're not, then AFAIK you have 2 solutions.  You can either
use rpath (generally discouraged, for reasons I may not understand,
but I agree for other reasons anway), or link with libR by filename
rather than by linker switch.

As in:

  gcc -o foo -lm /usr/lib/R/lib/libR.so

instead of

  gcc -o foo -lm -L /usr/lib/R/lib/ -lR

-- 
Clear skies,
Justin


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

Re: essential vs. required vs. base

[Russ Allbery]

Justin Pryzby <[EMAIL PROTECTED]> writes:

> Packages marked "Essential: yes" have to be operational before they are
> configured, and packages need not (and should not) depend on them, in
> the same was as they needn't and shouldn't to build-depend on
> build-essential packages such as gcc and make.  Essential packages are
> also the only ones which can be relied on to be working in postrm:purge.

> The priority system exists to help define dependencies .. packages
> cannot depend on other packages with a lower priority.  Policy indicates
> that "Priority: required" packages are thus marked because they are
> (mostly) needed by dpkg, which seems like a fine criteria.

> I'm including the context diff between essential packages and required
> ones.  Since essential implies required, why isn't there simply another
> priority class, instead of a separate "Essential" field??

Essential means that it's very difficult to remove the package and you
have to jump through extreme hoops to do so, and that removing it may
break the system.  As a result, no libraries are essential since libraries
are removed when they're upgraded.  They end up being essential in
practice because essential packages depend on them.  That's most of the
delta.

mawk isn't essential because awk has alternatives and mawk is just the
default choice.  Someone may want to install gawk and remove mawk, which
should continue to work.  sysv-rc and initscripts similarly, as I recall,
have possible alternatives or at least might.

dselect probably shouldn't be required any more.

debconf implements a protocol, and another implementation of the same
protocol should be allowed.  cdebconf is in progress, in fact.

That leaves the following as the only differences that I don't know the
story behind off-hand:

> +gcc-4.0-base
> +lsb-base
> +makedev
> +passwd
> +procps

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: essential vs. required vs. base

[Justin Pryzby]

On Wed, Nov 09, 2005 at 01:13:44PM -0800, Russ Allbery wrote:
> Justin Pryzby <[EMAIL PROTECTED]> writes:
> 
> > Packages marked "Essential: yes" have to be operational before they are
> > configured, and packages need not (and should not) depend on them, in
> > the same was as they needn't and shouldn't to build-depend on
> > build-essential packages such as gcc and make.  Essential packages are
> > also the only ones which can be relied on to be working in postrm:purge.
> 
> > The priority system exists to help define dependencies .. packages
> > cannot depend on other packages with a lower priority.  Policy indicates
> > that "Priority: required" packages are thus marked because they are
> > (mostly) needed by dpkg, which seems like a fine criteria.
> 
> > I'm including the context diff between essential packages and required
> > ones.  Since essential implies required, why isn't there simply another
> > priority class, instead of a separate "Essential" field??
> 
> Essential means that it's very difficult to remove the package and you
> have to jump through extreme hoops to do so, and that removing it may
> break the system.
Yes, but how is that different from Priority: required?  Removing
essential packages is difficult because dpkg will yell at you:

 This is an essential package - it should not be removed.

Priority required is defined in policy 2.5:

 `required'
  Packages which are necessary for the proper functioning of
  the system (usually, this means that dpkg functionality
  depends on these packages).  Removing an `required' package
  may cause your system to become totally broken and you may
  not even be able to use `dpkg' to put things back, so only
  do so if you know what you are doing.  Systems with only the
  `required' packages are probably unusable, but they do have
  enough functionality to allow the sysadmin to boot and
  install more software.

> As a result, no libraries are essential since libraries are removed
> when they're upgraded.
I noticed that; but aren't all packages removed when they're upgrade?

My question isn't so much "why are some required packages not
essential?", but "Why is there a special mechanism for 'essential'?".
Why essential just another priority, for which dpkg has special tests?

-- 
Clear skies,
Justin


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

Re: essential vs. required vs. base

[Russ Allbery]

Justin Pryzby <[EMAIL PROTECTED]> writes:
> On Wed, Nov 09, 2005 at 01:13:44PM -0800, Russ Allbery wrote:

>> Essential means that it's very difficult to remove the package and you
>> have to jump through extreme hoops to do so, and that removing it may
>> break the system.

> Yes, but how is that different from Priority: required?

Basically, there are times when you can, and want to, remove packages with
Priority: required.  But you don't get to do that with essential ones.

>> As a result, no libraries are essential since libraries are removed
>> when they're upgraded.

> I noticed that; but aren't all packages removed when they're upgrade?

Sorry, I was being sloppy in my wording.  The issue with libraries is that
the package name may change if the SONAME changes.  Changing the package
name of a package that's essential is incredibly painful.

> My question isn't so much "why are some required packages not
> essential?", but "Why is there a special mechanism for 'essential'?".
> Why essential just another priority, for which dpkg has special tests?

Historical reasons, probably.  The case it allows (an essential package
that's not required) doesn't sound useful.  There *is* the potential issue
that the Priority is somewhat under the control of ftp-master rather than
the package maintainer due to the override file, but I don't know that
that separation of powers is actually being used to any real purpose in
this specific case.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: How to add applications to IceWM menu

[Stan Vasilyev]

Unfortunately the Debian menu doesn't solve my problem because IceWM
doesn't support it. Basically the issue is that the software I'm
packaging, IceWM Control Center is strictly for IceWM and it doesn't
make sense to use it in other window managers. However, in KDE,
BlackBox, Fluxbox and Gnome I can get IceWM Control Center to appear in
the menu by using .desktop files or Debian /usr/share/menu but in IceWM
I have to edit a file /etc/X11/icewm/menu by hand and add the
application there.

Should I just forget about adding IceWM Control Center to the menu and
let the users do it themselves?

Jan Wagemakers wrote:

>Maybe  and
> is what you are looking
>for?
>


signature.asc
Description: OpenPGP digital signature

Re: RFS: irmp3 -- mp3 Jukebox (LIRC support)

[Erik Schanze]

Hi Daniel,

Daniel Baumann <[EMAIL PROTECTED]>:
> Erik Schanze wrote:
> > Your way will not fail, but could be improved.
> > The advantage of Build-Depends on autotools-dev is to have the
> > newest config.* stuff available. There is no need to include the
> > new config.* files into diff. If you do so, you don't need to
> > Build-Depend on autotools-dev, but your diff grows.
>
> Well, I beg to differ. Its important to have current
> config.{sub,guess} to ensure, that the package builds on the latest
> debian ports (e.g. kfreebsd), and sometimes.. if the files are really
> outdated, its even essential to be buildable on !i386.
>
Yes, it's important to have the latest config.* files at build time, but 
isn't the autotools-dev depends responsible for it, that they are 
available under /usr/share/misc/ at buildtime?
Then we link to it and have it. The original ones are out of interest. 
(Should be moved aside.)
Why should the config.* files included into the diff?
Aren't autotools-dev available on ports you mention?

> Second, to build-depend on autotools-dev and importing them via the
> clean-target into the diff.gz. is the usual way to handle this.
>
And the diff grows with the same content in every (related) package.
Sounds not like a good solution for me. 


Wondering,
Erik


-- 
 www.ErikSchanze.de *
 Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
COMTEC in Dresden, 09. - 11. November 2005  *
  Info: http://www.messe-comtec.de/ *


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

Re: RFS: bubbbros

[Justin Pryzby]

On Mon, Nov 07, 2005 at 09:46:38PM -0500, Daniel Milstein wrote:
> I was wondering if anyone would be interested in sponsoring bubnbros, a 2d 
> platform game that is a clone of "Bubble Bobble". Parts of it are released 
> under the MIT License and the rest is under the Artistic LIcense. Its ITP bug 
> number is 337559 and the package can be found at 
> http://mentors.debian.net/debian/pool/main/b/bubbros/ (the source package 
> name is bubbros because that is what upstream calls the tarball but the 
> binary packages are called bubnbros because that is what upstream calls the 
> binary and the program itself). Its upstream 
> source is http://bub-n-bros.sf.net. The package is split into a platform 
> independant part, which contains python scripts and data files, called 
> bubnbros-minimal, and a platform dependant part, which contains extension 
> libraries written in C which enhance the game but are not neccessary in order 
> to play it, called bubnbros.
> 
> Lintian and linda both complain about image files in /usr/lib. However, the 
> package source code depends on images and library files to be in the same 
> directory. If that directory was in /usr/share, then there would be an 
> executable in /usr/share and lintian and linda would still complain.
So its an upstream bug; have you mailed them about it?  Have you
consdiered how difficult it would be to fix?  Would be neat if you
could mail a patch to the upstream authors.

> Lintian also complains about the menu file being in the "old
> format", even though it follows the latest format from debian.org,
> as far as I can tell. There are no other lintian or linda errors.
I donno..

-- 
Clear skies,
Justin


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

Re: RFS: irmp3 -- mp3 Jukebox (LIRC support)

[Justin Pryzby]

On Wed, Nov 09, 2005 at 11:30:23PM +0100, Erik Schanze wrote:
> Hi Daniel,
> 
> Daniel Baumann <[EMAIL PROTECTED]>:
> > Erik Schanze wrote:
> > > Your way will not fail, but could be improved.
> > > The advantage of Build-Depends on autotools-dev is to have the
> > > newest config.* stuff available. There is no need to include the
> > > new config.* files into diff. If you do so, you don't need to
> > > Build-Depend on autotools-dev, but your diff grows.
> >
> > Well, I beg to differ. Its important to have current
> > config.{sub,guess} to ensure, that the package builds on the latest
> > debian ports (e.g. kfreebsd), and sometimes.. if the files are really
> > outdated, its even essential to be buildable on !i386.
> >
> Yes, it's important to have the latest config.* files at build time, but 
> isn't the autotools-dev depends responsible for it, that they are 
> available under /usr/share/misc/ at buildtime?
> Then we link to it and have it. The original ones are out of interest. 
> (Should be moved aside.)
> Why should the config.* files included into the diff?
> Aren't autotools-dev available on ports you mention?
I think the idea is that then the .diff defines the entire state of
the package as it existed when the maintainer created the .deb for his
architecture.

-- 
Clear skies,
Justin


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

RFS: ccbuild - C++ source scanning build utility (ITP 338341)

[Bram Neijt]

ccbuild is a C++ source scanning build utility. This request is for
the new 1.5.0 version that is just out.

I have posted all my debian package work at:
 http://www.ai.rug.nl/~bneijt/debian/

The sponsors record can be found at:
 http://sponsors.debian.net/viewpkg.php?id=134

The ITP can be found here:
  http://bugs.debian.org/338341

ccbuild is an automated build utility for development of C++ programs
when the source is highly seperated and distributed over directories,
without the need to edit scripts or register files. Next to simply
building the program, it can generate include graphs, makefiles and
A-A-P files. It also supports MD5 hashing, header precompilation. Code
seperation is based on Large Scale C++ design by John Lakos.

Compile time dependencies are: flex
Runtime dependencies are only the general libraries.

Thanking for reading this,
  Bram Neijt

--
Key fingerprint = CFF9 A55D 6677 7EF2 035D  7695 639D 107C EDB3 D318

Conflict with kernel versions?

[David Given]

I'm interested in doing a package for spey, my greylisting SMTP proxy 
(http://spey.sf.net). This isn't going to happen immediately, but I'm due to 
make another upstream release soon, and if that goes well I want to start 
work on the package.

Unfortunately, the application has its own coroutine library that turns out to 
have a nasty conflict with linuxthreads (due to allocating its own stacks, 
which causes linuxthreads to crash). linuxthreads is used as part of glibc on 
2.4 kernels. 2.6 kernels, such as the one I did the development on, are fine.

Is it possible to specify this as part of the package dependencies, and if so 
how, or am I just going to have to document the fact that it'll crash on 
startup on a 2.4 system? Is this, in fact, not appropriate for inclusion in 
Debian because of this?

(And if anyone wants to suggest a real fix, please get in touch. The *only* 
reason I'm asking about this is because I can't find any way of working 
around the problem.)

-- 
+- David Given --McQ-+ "I never really understood how there could be
|  [EMAIL PROTECTED]| things that would drive you insane just because you
| ([EMAIL PROTECTED]) | knew them until I ran into Windows." --- Peter da
+- www.cowlark.com --+ Silva



pgpOREA8UGZ53.pgp
Description: PGP signature

Re: Conflict with kernel versions?

[Justin Pryzby]

On Thu, Nov 10, 2005 at 12:38:26AM +, David Given wrote:
> I'm interested in doing a package for spey, my greylisting SMTP proxy 
> (http://spey.sf.net). This isn't going to happen immediately, but I'm due to 
> make another upstream release soon, and if that goes well I want to start 
> work on the package.
> 
> Unfortunately, the application has its own coroutine library that turns out 
> to 
> have a nasty conflict with linuxthreads (due to allocating its own stacks, 
> which causes linuxthreads to crash). linuxthreads is used as part of glibc on 
> 2.4 kernels. 2.6 kernels, such as the one I did the development on, are fine.
> 
> Is it possible to specify this as part of the package dependencies, and if so 
> how, or am I just going to have to document the fact that it'll crash on 
> startup on a 2.4 system? Is this, in fact, not appropriate for inclusion in 
> Debian because of this?
> 
> (And if anyone wants to suggest a real fix, please get in touch. The *only* 
> reason I'm asking about this is because I can't find any way of working 
> around the problem.)
Have you tried echo -n 1 >/proc/sys/vm/legacy_va_layout?
(I don't know if its 1, actually, mb try the values 0 through 3).

You can have the same effect with personality(), but seems to require
an exec().

I'd be interested if this was the case; let me know.

-- 
Clear skies,
Justin


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

Re: RFS: statist - Small and fast terminal-based statistics program

[Jakson A. Aquino]

Hi,

On Wed, Nov 09, 2005 at 07:49:15PM +0100, Nico Golde wrote:
> Ok here are the comments:
>  - changelog file will not close an ITP

I added (Closes: #155073), but this bug was already
automatically closed on 22 Sep 2005 because there was no
activity around it in 365 days. Is there any problem in
trying to close an already closed bug? 

This is currently the only doubt that I have, and I would
like to solve it before uploading the .diff.gz and .dsc
files again.

>  - add one space before the Homepage tag in control (like 
>described in developers reference)

Added.

>  - consider to add Upstream Author tag to copyright with 
>email addresses of them (not a bug)

Added for the two current developers. The original author of
statist is no longer working in its development, so I didn't
include his email address.

>  - delete unneeded comments in rules (sample file etc.)

Deleted.

>  - the website in the readme is not the same as in control 
>and copyright

The website in the README of the original tarball is
outdated. The current homepage is the one in the control and
copyright. The README also mostly has information on how to
compile and install from source, so I'm not including it in
the package. The README that I included was that of doc
subdirectory.

>  - is dh_fixperms really needed?

I removed it.

>  - dh_installexamples is not needed

Deleted.

>  -  lintian -I ../*.changes
> I: statist: hyphen-used-as-minus-sign usr/share/man/man1/statist.1.gz:7
> I: statist: hyphen-used-as-minus-sign usr/share/man/man1/statist.1.gz:8
> I: statist: hyphen-used-as-minus-sign usr/share/man/man1/statist.1.gz:64

Fixed: Replaced - with \-

Thank your very much for your help! 

Jakson



signature.asc
Description: Digital signature

Depends: awk -- Is that required?

[Bob Proulx]

I need a clarification because I am confused.  If I have a script that
uses awk do I need the package to "Depends: awk"?  Or is awk like
basename where we are able to assume it is on the system without any
explicit dependencies?

I see that many packages do "Depends: awk".  But awk is an alternative
and mawk is "Priority: required" so I would not think so.  But gawk
provides awk and is "Priority: optional" but with a higher alternative
priority too and so that "required" mawk is almost never used.  (I
always install gawk as awk for its better features.)

If the package used gawk specific features then the decision would be
easy.  It would need to depend upon gawk.  But it only uses basic awk
features and so any of the alternatives is sufficient.

Thanks for you knowledge in this.

Bob


signature.asc
Description: Digital signature

Re: Depends: awk -- Is that required?

[Roberto C. Sanchez]

On Wed, Nov 09, 2005 at 06:43:51PM -0700, Bob Proulx wrote:
> I need a clarification because I am confused.  If I have a script that
> uses awk do I need the package to "Depends: awk"?  Or is awk like
> basename where we are able to assume it is on the system without any
> explicit dependencies?
> 
> I see that many packages do "Depends: awk".  But awk is an alternative
> and mawk is "Priority: required" so I would not think so.  But gawk
> provides awk and is "Priority: optional" but with a higher alternative
> priority too and so that "required" mawk is almost never used.  (I
> always install gawk as awk for its better features.)
> 
> If the package used gawk specific features then the decision would be
> easy.  It would need to depend upon gawk.  But it only uses basic awk
> features and so any of the alternatives is sufficient.
> 
> Thanks for you knowledge in this.

I suspect that it is not necessary:

$ apt-cache show mawk |grep "Provides\|Priority"
Priority: required
Provides: awk

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


pgpiLD27iIuP3.pgp
Description: PGP signature

Re: Depends: awk -- Is that required?

[Steve Langasek]

On Wed, Nov 09, 2005 at 06:43:51PM -0700, Bob Proulx wrote:
> I need a clarification because I am confused.  If I have a script that
> uses awk do I need the package to "Depends: awk"?  Or is awk like
> basename where we are able to assume it is on the system without any
> explicit dependencies?

> I see that many packages do "Depends: awk".  But awk is an alternative
> and mawk is "Priority: required" so I would not think so.  But gawk
> provides awk and is "Priority: optional" but with a higher alternative
> priority too and so that "required" mawk is almost never used.  (I
> always install gawk as awk for its better features.)

> If the package used gawk specific features then the decision would be
> easy.  It would need to depend upon gawk.  But it only uses basic awk
> features and so any of the alternatives is sufficient.

> Thanks for you knowledge in this.

awk is "virtually essential": it can't be Essential: yes because that would
prevent removing mawk in favor of gawk, but awk is a dependency of another
essential package to ensure that you can use basic awk functionality without
having to depend on it.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Depends: awk -- Is that required?

[Steve Langasek]

On Wed, Nov 09, 2005 at 09:57:37PM -0500, Roberto C. Sanchez wrote:
> On Wed, Nov 09, 2005 at 06:43:51PM -0700, Bob Proulx wrote:
> > I need a clarification because I am confused.  If I have a script that
> > uses awk do I need the package to "Depends: awk"?  Or is awk like
> > basename where we are able to assume it is on the system without any
> > explicit dependencies?

> > I see that many packages do "Depends: awk".  But awk is an alternative
> > and mawk is "Priority: required" so I would not think so.  But gawk
> > provides awk and is "Priority: optional" but with a higher alternative
> > priority too and so that "required" mawk is almost never used.  (I
> > always install gawk as awk for its better features.)

> > If the package used gawk specific features then the decision would be
> > easy.  It would need to depend upon gawk.  But it only uses basic awk
> > features and so any of the alternatives is sufficient.

> > Thanks for you knowledge in this.

> I suspect that it is not necessary:

> $ apt-cache show mawk |grep "Provides\|Priority"
> Priority: required
> Provides: awk

Right conclusion, wrong rationale.  A package being Priority: required does
not excuse you from an explicit dependency.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Package that depends on ming

[Paul Wise]

On Wed, 2005-11-09 at 21:08 +0100, Joost van Baal wrote:

> > Since ming is not in Debian anymore,
> 
> You're talking about libming, which is still supported in woody
> (oldstable).  Do you know why it didn't make it to sarge?  It might be
> possible to get it re-enter Debian.  (Just saw upstream released 0.3.0,
> which never was shipped with Debian.)

From http://ftp-master.debian.org/removals.txt

[Date: Mon, 12 Jan 2004 22:30:29 -0500] [ftpmaster: James Troup]
Removed the following packages from unstable:

   libming | 0.2a.cvs20030716-2 | source, alpha, arm, hppa, i386, ia64, m68k, 
mips, mipsel, powerpc, s390, sparc
libming-dev | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, 
mipsel, powerpc, s390, sparc
libming-fonts-openoffice |  0.1-2 | source, all
libming-util | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, 
mipsel, powerpc, s390, sparc
libswf-perl | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, 
mipsel, powerpc, s390, sparc
 php4-ming | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, 
mipsel, powerpc, s390, sparc
python2.1-ming | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, 
mipsel, powerpc, s390, sparc
python2.2-ming | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, 
mipsel, powerpc, s390, sparc
Closed bugs: 166973 166990

--- Reason ---
RoQA; orphaned, dead upstream, grave bugs, unused.
--

Upstream CVS is slowly ticking over (last change 3 weeks ago), and if
they make an actual release, I'll be adding ming to the list of osflash
related packages to do on http://osflash.org/debian_packaging

> > should the
> > package be on the non-free section? 
> 
> If it _depends_ upon libming, your program can't be shipped with Debian
> as long as libming is not in Debian.

It can be shipped in contrib though. contrib is for free packages with
dependencies (free or otherwise) that are not in debian.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Package that depends on ming

[Steve Langasek]

On Thu, Nov 10, 2005 at 12:29:27PM +0800, Paul Wise wrote:
> > If it _depends_ upon libming, your program can't be shipped with Debian
> > as long as libming is not in Debian.

> It can be shipped in contrib though. contrib is for free packages with
> dependencies (free or otherwise) that are not in debian.

True, but uploading a package to contrib instead of main because you haven't
*bothered* to package the deps is pretty lame.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Package that depends on ming

[Aníbal Monsalve Salazar]

On Thu, Nov 10, 2005 at 12:29:27PM +0800, Paul Wise wrote:
>On Wed, 2005-11-09 at 21:08 +0100, Joost van Baal wrote:
>
>>>Since ming is not in Debian anymore,
>>
>>You're talking about libming, which is still supported in woody
>>(oldstable).  Do you know why it didn't make it to sarge?  It might be
>>possible to get it re-enter Debian.  (Just saw upstream released 0.3.0,
>>which never was shipped with Debian.)

Mattias Nordstrom is trying to get it back in unstable.

See http://bugs.debian.org/295760

>From http://ftp-master.debian.org/removals.txt
>
>[Date: Mon, 12 Jan 2004 22:30:29 -0500] [ftpmaster: James Troup]
>Removed the following packages from unstable:
>
>   libming | 0.2a.cvs20030716-2 | source, alpha, arm, hppa, i386, ia64, m68k, 
> mips, mipsel, powerpc, s390, sparc
>libming-dev | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, 
>mipsel, powerpc, s390, sparc
>libming-fonts-openoffice |  0.1-2 | source, all
>libming-util | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, 
>mipsel, powerpc, s390, sparc
>libswf-perl | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, 
>mipsel, powerpc, s390, sparc
> php4-ming | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, mips, 
> mipsel, powerpc, s390, sparc
>python2.1-ming | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, 
>mips, mipsel, powerpc, s390, sparc
>python2.2-ming | 0.2a.cvs20030716-2 | alpha, arm, hppa, i386, ia64, m68k, 
>mips, mipsel, powerpc, s390, sparc
>Closed bugs: 166973 166990
>
>--- Reason ---
>RoQA; orphaned, dead upstream, grave bugs, unused.
>--
>
>Upstream CVS is slowly ticking over (last change 3 weeks ago), and if
>they make an actual release, I'll be adding ming to the list of osflash
>related packages to do on http://osflash.org/debian_packaging
>
>>>should the
>>>package be on the non-free section? 
>>
>>If it _depends_ upon libming, your program can't be shipped with Debian
>>as long as libming is not in Debian.
>
>It can be shipped in contrib though. contrib is for free packages with
>dependencies (free or otherwise) that are not in debian.
>
>-- 
>bye,
>pabs
>
>http://wiki.debian.org/PaulWise

Aníbal Monsalve Salazar
--
 .''`. Debian GNU/Linux
: :' : Free Operating System
`. `'  http://debian.org/
  `-   http://v7w.com/anibal


signature.asc
Description: Digital signature

NOOB: Do I seek a sponsor before applying as a new maintainer?

[DoyenGuy]

After looking into the whole "new maintainer" process and application
and documentation and tomes of webpages on the Debian website, I
encountered a question.  I sent an email three days ago to what I
thought was the most logical address, the Debian "Front Desk", and
even though I'm not "involved" right now I thought I'd hear from them
reasonably promptly, but not as of yet have I gotten anything back.

What follows is what I sent to the 'front desk', and what I know ask
of the mentors list...

So I turn to the Debian mentors list, where I hopefully will find an
answer and direction.

I have written a program (and continue to improve) called ProShield
(proshield.sf.net) that I would like to get put into the official
debian apt repositories.  This involves a "new maintainer" application
process, as well as a lot of reading and other stuff.

I have subscribed to the debian-devel and debian-mentor mailing lists,
and the documentation on the website confuses me a little.  Do I
express who I am, what my program is, and my desire to find a sponsor
for my package on the debian-mentor list before I apply to be a
maintainer?

What do I do?

Tom

Re: NOOB: Do I seek a sponsor before applying as a new maintainer?

[Joost van Baal]

Op do 10 nov 2005 om 12:20:55 -0500 schreef DoyenGuy:
> 

> I have written a program (and continue to improve) called ProShield
> (proshield.sf.net) that I would like to get put into the official
> debian apt repositories.  This involves a "new maintainer" application
> process, as well as a lot of reading and other stuff.

It doesn't necessarily need a "new maintainer" application.

> What do I do?

Read _yet_ more!  ;-)

See "How do I add a new package to the archive?" on
http://people.debian.org/~mpalmer/debian-mentors_FAQ.html .

Bye,

Joost



signature.asc
Description: Digital signature

Re: NOOB: Do I seek a sponsor before applying as a new maintainer?

[Justin Pryzby]

On Thu, Nov 10, 2005 at 12:20:55AM -0500, DoyenGuy wrote:
> After looking into the whole "new maintainer" process and application
> and documentation and tomes of webpages on the Debian website, I
> encountered a question.  I sent an email three days ago to what I
> thought was the most logical address, the Debian "Front Desk", and
> even though I'm not "involved" right now I thought I'd hear from them
> reasonably promptly, but not as of yet have I gotten anything back.
> 
> What follows is what I sent to the 'front desk', and what I know ask
> of the mentors list...
> 
> So I turn to the Debian mentors list, where I hopefully will find an
> answer and direction.
> 
> I have written a program (and continue to improve) called ProShield
> (proshield.sf.net) that I would like to get put into the official
> debian apt repositories.  This involves a "new maintainer" application
> process, as well as a lot of reading and other stuff.
> 
> I have subscribed to the debian-devel and debian-mentor mailing lists,
> and the documentation on the website confuses me a little.  Do I
> express who I am, what my program is, and my desire to find a sponsor
> for my package on the debian-mentor list before I apply to be a
> maintainer?
> 
> What do I do?
If you want to be a package maintainer, then you will want to
demonstrate your skill at maintaining packages, by finding a sponsor
to upload them for you.  Then you can apply at NM. 

-- 
Clear skies,
Justin


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

Re: Depends: awk -- Is that required?

[Recai Oktas]

* Steve Langasek [2005-11-09 19:25:40-0800]
> awk is "virtually essential": it can't be Essential: yes because that would
> prevent removing mawk in favor of gawk, but awk is a dependency of another
> essential package to ensure that you can use basic awk functionality without
> having to depend on it.

Just to make things a little clearer, the above is the excerpt from the
changelog of 'base-files' (an essential package):

  base-files (1.7) unstable; urgency=low

  
* Added "Depends: awk", so that awk is a "virtual essential package".
[...]

  [dated as 23 Feb 1998]

-- 
roktas


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

Re: RFS: statist - Small and fast terminal-based statistics program

[Jakson A. Aquino]

Hi,

On Wed, Nov 09, 2005 at 10:46:32PM -0200, Jakson A. Aquino wrote:
> I added (Closes: #155073), but this bug was already
> automatically closed on 22 Sep 2005 because there was no
> activity around it in 365 days. Is there any problem in
> trying to close an already closed bug? 
> 
> This is currently the only doubt that I have, and I would
> like to solve it before uploading the .diff.gz and .dsc
> files again

I wrote to Carleos Artime and he reopened the bug. Then I
uploaded the files.  The new links are:

http://wald.intevation.org/frs/download.php/45/statist_1.3.1-1.diff.gz
http://wald.intevation.org/frs/download.php/46/statist_1.3.1-1.dsc

Thanks,

Jakson


signature.asc
Description: Digital signature