On Wed, 24 May 2006, Wolfgang Lonien wrote:
wow, pretty bad news in this week's DWN about cyrus-sasl2 being
orphaned. I checked popcon, and it has some 12.000 installations, so:
Yes, and it is one of the hariest, most horrible packages to maintain I know
of.
I'd really like to do something
On Sun, 12 Feb 2006, Manoj Srivastava wrote:
This is interesting. When I remove a file completely from
./debian, as I do in the case of fvwm, diff says ignoring deletion
of files So, if I had instead just truncaterd the file, it
would be removed from the unpacked tree, while
On Fri, 03 Feb 2006, Bas Wijnen wrote:
On re-reading this message, it seems to have a harsh tone. Sorry about that,
that was not my intention. Also I don't want to start a flame-war or
anything, but I do want either me or the others (whoever that includes)
Ah, no I didn't take that as harsh,
On Wed, 18 Jan 2006, Thijs Kinkhorst wrote:
In a more general sense, it's important to note that the
fixed-in-experimental tag is deprecated, and definately not necessary
It is kinda hard to consider it deprecated while DAK still sets it instead
of doing a proper job of issuing notfound
On Wed, 18 Jan 2006, Steve Langasek wrote:
On Wed, Jan 18, 2006 at 09:29:35AM -0200, Henrique de Moraes Holschuh wrote:
On Wed, 18 Jan 2006, Thijs Kinkhorst wrote:
In a more general sense, it's important to note that the
fixed-in-experimental tag is deprecated, and definately
On Wed, 18 Jan 2006, Frank Küster wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
No, as close commands ARE clearly deprecated as well, and not at all
equivalent to adding a tag. We are taliking about uploads to experimental,
after all.
AFAIK, [EMAIL PROTECTED] should
On Wed, 18 Jan 2006, Thijs Kinkhorst wrote:
There's currently no other way to specify a fixed-version other than
mailing '-done' or using 'close. Mailing -done is not always
Refer to the found and notfound commands in the BTS reference.
notfound seems to do what you want, to me. Or maybe I
On Wed, 18 Jan 2006, Steve Langasek wrote:
AFAIK, [EMAIL PROTECTED] should be used for unstable uploads (it already
is, I
think), and notfound commands to [EMAIL PROTECTED] should be used instead of
fixed-in-experimental tags.
Wrong. notfound commands don't do anything that's at all
On Wed, 18 Jan 2006, Henrique de Moraes Holschuh wrote:
On Wed, 18 Jan 2006, Thijs Kinkhorst wrote:
There's currently no other way to specify a fixed-version other than
mailing '-done' or using 'close. Mailing -done is not always
Refer to the found and notfound commands in the BTS
On Sat, 14 Jan 2006, Bas Wijnen wrote:
Of course I know the classical argument against this: To build a program, you
should only need to do ./configure;make;make install. configure is the
platform independant script, autoconf should only be used by upstream.
Well, that's an stupid argument
On Sat, 14 Jan 2006, Russ Allbery wrote:
The problem is, in a nutshell, this doesn't actually work reliably. If
It does inside Debian (you can explicitly choose a given version, and
upgrade to the next only after some testing). It *mostly* does among minor
versions of the autotools, if
On Fri, 13 Jan 2006, Steve Langasek wrote:
There are *always* libraries in a state of transition in Debian. Using the
Debian libtool means limiting those transitions to packages which have a
valid reason for depending on the transitioning library, instead of giving
us transitions that ripple
On Fri, 13 Jan 2006, Florian Ernst wrote:
I thought I understood at least the reason to include diffs for a
config.guess and config.sub. But IMHO relibtooling is only needed when
certain libraries are in a state of transitions. Could you (or Florian (or
autotools dev maintainer hat on
On Tue, 20 Dec 2005, J. Bruce Fields wrote:
On Tue, Dec 20, 2005 at 03:32:42PM -0200, Henrique de Moraes Holschuh wrote:
On Tue, 20 Dec 2005, J. Bruce Fields wrote:
On Tue, Dec 20, 2005 at 08:47:44AM -0200, Henrique de Moraes Holschuh
wrote:
Since bzr (and other arch derivates) have
On Tue, 20 Dec 2005, Russ Allbery wrote:
You just lost the people that I'm talking about. I can explain a
changeset, but merges are deep black magic that are extremely difficult to
understand except at a highly abstract level, and when using a distributed
VCS, they have to deal with merges
On Mon, 19 Dec 2005, Russ Allbery wrote:
Ben Finney [EMAIL PROTECTED] writes:
In other words, a distributed VCS allows all parties to manage their own
repositories equally, and the project can nominate one of them the
official central repository, without impacting everyone's ability to
Hi J.!
On Tue, 20 Dec 2005, J. Bruce Fields wrote:
On Tue, Dec 20, 2005 at 08:47:44AM -0200, Henrique de Moraes Holschuh wrote:
Since bzr (and other arch derivates) have the benefit of NEVER forgeting
which changesets are in a tree, I prefer them over any other distributed
system
On Mon, 19 Dec 2005, Stefan Potyra wrote:
I'd object to this, since one of the goals would be to make it easy to review
packages. So basically you'd need exactly one central place, where the
current version of a sourcepackage can be found, and can be reviewed. However
I'm not quite sure
On Thu, 15 Dec 2005, Don Armstrong wrote:
Why not just something like:
0 0 * * * at now + $(( $RANDOM \% 1440 )) minutes [...]
Because at is something you should never have installed (it is the very
first thing I purge, after fixing the dumb wide-open defaults we use for
hosts.allow and
On Thu, 03 Nov 2005, Steve Langasek wrote:
On Thu, Nov 03, 2005 at 10:32:07PM -0500, Peter S Galbraith wrote:
Problem summary: Using debconf and rc.d script hangs package installation
I am merging packages `powstatd' and `powstad-crypt' into a single new
`powstatd' package with encryption
On Sat, 05 Nov 2005, Cameron Patrick wrote:
Henrique de Moraes Holschuh wrote:
And the proper fix is to call db_stop AND of course fix the daemon to close
open fds it doesn't need. Unfortunately, there are only kludgy ways to do
so as the kernel won't tell you which FDs you have
On Tue, 01 Nov 2005, Nathanael Nerode wrote:
Frank Lichtenheld wrote:
On Tue, Nov 01, 2005 at 11:21:41AM -0400, -.JavaManiac.- wrote:
I have the next linda-warning :
W: libefltk2.0-dev; Shared object /usr/bin/ecalc is linked with
version 6 and 5of libstdc++.
snip
I can't tell of
On Sat, 29 Oct 2005, Steve Langasek wrote:
On Sat, Oct 29, 2005 at 09:12:27AM -0200, Henrique de Moraes Holschuh wrote:
On Sat, 29 Oct 2005, skaller wrote:
compiler ABI changes (I believe that doesn't apply here since
gcc 4.x uses same C ABI as gcc 3.4, not sure about C++ though
On Fri, 21 Oct 2005, Jean-Marc Ranger wrote:
What's the correct way to handle duplicate entres in bugs.debian.org ?
Merge ? Personal feeling would be to close one immediately while
providing a link somehow.
Just merge them. It doesn't matter if the duplicates are caused by a MTA
snafu, or
On Mon, 17 Oct 2005, Simon Richter wrote:
Both solutions are correct, modifying the Makefile is easier to
understand for someone else looking at the package and will also show a
Modifying an *automake* generated makefile and easier to understand do not
belong in the same sentence.
Fixing
On Thu, 06 Oct 2005, Rogério Brito wrote:
So, I guess that's not only me that would benefit from some light from
people from debian-mentors on what is the best-current-practice on
getting accented characters on manpages.
Basically, until UTF8 support is fully deployed for manpages (it isn't
On Thu, 06 Oct 2005, Norbert Preining wrote:
Well if the Name of the author contains latin1 characters, I would
suggest to include the letters. Otherwise it is just plain wrong.
You don't have that option. Transliterate it just like our poor CJK friends
have been forced to do for a LONG time
On Thu, 22 Sep 2005, Vedran Fura? wrote:
Is it OK to have more than debian directory (and files under it) in
package_version-rev.diff.gz? I have a lot of other diffs outside debian/
(in aclocal.m4, Makefile.in,...). The problem is that after I run
./configure and then make distclean, I don't
On Thu, 15 Sep 2005, Rafael Laboissiere wrote:
I buy Sven's arguments in favor of adding -nonfree. I would also strip the
lib at the beginning of the name. The upstream Perl module is called
Parse-RecDescent, so I would call the package parse-recdescent-doc-nonfree.
What do you think?
Stick
On Thu, 15 Sep 2005, Rafael Laboissiere wrote:
Well, the new package will not contain a Perl module, so I do not see the
need to sticking to the conventions (cf section 4.2 of the Debian Perl
We know what to guess as its name, that along is good enough reason IMHO.
At any rate, I guess you
On Fri, 09 Sep 2005, Joe Smith wrote:
news:[EMAIL PROTECTED]
Don't. /etc/inittab is critical infrastructure on every system where it is
used, NEVER EVER touch it.
Document what the user has to do to activate the package, instead, and let
him activate it where he wants, the way he wants.
On Mon, 12 Sep 2005, Ben Finney wrote:
On 11-Sep-2005, Henrique de Moraes Holschuh wrote:
Then tell the user that, and DO NOT TOUCH /etc/inittab.
Unless by using a well-defined interface for doing so. To my
Well, a broken inittab is a nightmare to repair for anyone without
console access
On Fri, 09 Sep 2005, Eddy Petri?or wrote:
The application I want to package, qingy, is in fact a replacement for
getty and it needs to modify /etc/inittab.
Don't. /etc/inittab is critical infrastructure on every system where it is
used, NEVER EVER touch it.
Document what the user has to do to
On Sat, 03 Sep 2005, Steve Langasek wrote:
#: mmainwindow.cpp:625
msgid 5 minutes warning
msgstr 5 minutos aguardando
- aguardando means waiting, not warning
Oh dear. And people ask me why I refuse to have LC_MESSAGES set to pt_BR,
even though it is my native language. I would send a lot of
On Sun, 04 Sep 2005, Oohara Yuuma wrote:
to it is not very safe. I have no other way to contact him.
What should I do?
If he is a contributor to a package you take care of, write a message there
that he must send you a gpg-signed message from his new address.
Apparently he does not have a gpg
On Thu, 18 Aug 2005, Ben Finney wrote:
This has happened at at least a dozen sites recently. I'm getting
really sick of this. Is everyone using the same frigging regex to
validate email addresses? Well, whatever the cause, it's *wrong*.
Please stop validating email addresses against a regex.
On Sat, 13 Aug 2005, Armin Berres wrote:
You have two good choices, and one bad choice for packaging upstream
source which uses automake and autoconf and contains generated files:
1. Tolerate the big diff size, and run the autotools stuff before you
create the debian source package. This is
On Fri, 12 Aug 2005, Goswin von Brederlow wrote:
On the other hand, if you run them during build then you MUST 'unrun'
them in the clean target. Otherwise every build will get a (potentialy
hugely) different diff.gz file.
No. Just rm -f all autogenerated crap in debian/rules's clean target as
On Fri, 12 Aug 2005, Steve Langasek wrote:
On Fri, Aug 12, 2005 at 01:50:33PM +0200, Daniel Leidert wrote:
Aside from wasting (a little)
space in the archive, that makes it harder for NMUers or passing
developers
to see what's going on in your package.
In this case, you could use
On Thu, 09 May 2002, Marc Haber wrote:
From the docs I found, there is no legitimate reason for any package
to define rpath on a Debian system. Is this correct? Does this also
apply to other Linux systems?
It is correct for anything that shall end up in the usual ld.so directories.
It does not
On Sun, 01 May 2005, Carlos Z.F. Liu wrote:
On Sat, Apr 30, 2005 at 11:54:19AM +0200, Goswin von Brederlow wrote:
Read /usr/share/doc/autotools-dev/README.Debian.gz please.
Thanks for the pointer. But it doesn't answer my question.
I can't really add documentation on autotools-dev about
On Sat, 30 Apr 2005, Daniel Leidert wrote:
need to put the source into contrib/non-free? The situation: I have a
GPL licensed, python based application, which needs python2.3-profiler
(non-free), so the binary package can't go into main. Therefor i will
put it into contrib. Do I have to assign
On Sat, 30 Apr 2005, Daniel Leidert wrote:
Only that I really understand it: Following your answer, let's say there
is an application which provides some extra functionality, but these
extra-functions need a package outside main to compile. The core
functionality does not need a package
On Mon, 18 Apr 2005, Milan Zamazal wrote:
HdMH == Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
HdMH or tla-buildpackage (using bazaar, NOT tla)
Why not tla?
I can't condone the braindamaged user interface tla has. Bazaar is at least
fixing it to be far more useable
On Wed, 13 Apr 2005, Christoph Berg wrote:
Re: Jamie Jones in [EMAIL PROTECTED]
Can anybody suggest some good revision control systems for maintaining
Debian packages. I'm about to outgrow using RCS on the debian directory
and wanted to get an idea of what other maintainers are using for
On Wed, 30 Mar 2005, Jeroen van Wolffelaar wrote:
This should be better documented indeed, but most if not all tools
Time to file a bug report. What is the package responsible for the BTS
documentation on the web?
--
One disk to rule them all, One disk to find them. One disk to bring
them
On Sat, 01 Jan 2005, Miriam Ruiz wrote:
Thanks, i'll try to find it. I couldn't find it in
http://packages.debian.org/, and the only package i
found for that program is an old version in
www.apt-get.org.
http://snapshot.debian.org:
On Mon, 27 Dec 2004, Alejandro Exojo wrote:
because upstream used automake 1.7.6 and unstable now haves 1.7.9 (in
automake1.7). This differences are now added to the diff.gz, but this doesn't
sounds to me the proper way.
There is no proper way. You have two good choices, and one bad choice
On Fri, 24 Dec 2004, Tilman Koschnick wrote:
| Built successfully
|
| NOTE: The package could have used binaries from the following packages
| (access time changed) without a source dependency:
| python-dev: /usr/bin/python
| xlibs-dev: /usr/X11R6/lib/libICE.so /usr/X11R6/lib/libX11.so
On Wed, 22 Dec 2004, Mark Roach wrote:
On Wed, 2004-12-22 at 11:41 -0500, Mark Roach wrote:
On Wed, 2004-12-22 at 23:45 +1100, Matthew Palmer wrote:
You can do all of the Debian-specific maintenance in a separate debian
branch of your revision control system (you do *use* a good revision
On Sat, 18 Dec 2004, Erinn Clark wrote:
How do you deal with new upstream releases? The general answers I'm getting
I'd suggest using a version control system (even a lame one such as CVS), so
that you know exactly what changed from one upstream to another, and update
the debian/ stuff and any
On Thu, 28 Oct 2004, David Everly wrote:
Is there some mechanism or alternative for using uupdate so that any
upstream debian directory can be removed before patching?
Repack the upstream tarball sans the bogus debian/ dir, or use one of the
unpack-tarball-on-build-tree/-and-patch packaging
On Thu, 28 Oct 2004, Frank Küster wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] schrieb:
Repack the upstream tarball sans the bogus debian/ dir, or use one of the
unpack-tarball-on-build-tree/-and-patch packaging styles...
Why not just replace the upstream debian dir with your
On Thu, 28 Oct 2004, Frank Küster wrote:
I see no reason for repackaging in this case. It is much better to just
delete the upstream debian directory in the unpacked sources and copy
As I said, diff/patch cannot delete files in a debian package.
--
One disk to rule them all, One disk to
On Thu, 28 Oct 2004, David Everly wrote:
Is there some mechanism or alternative for using uupdate so that any
upstream debian directory can be removed before patching?
Repack the upstream tarball sans the bogus debian/ dir, or use one of the
unpack-tarball-on-build-tree/-and-patch packaging
On Thu, 28 Oct 2004, Frank Küster wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] schrieb:
Repack the upstream tarball sans the bogus debian/ dir, or use one of the
unpack-tarball-on-build-tree/-and-patch packaging styles...
Why not just replace the upstream debian dir with your
On Thu, 28 Oct 2004, Frank Küster wrote:
I see no reason for repackaging in this case. It is much better to just
delete the upstream debian directory in the unpacked sources and copy
As I said, diff/patch cannot delete files in a debian package.
--
One disk to rule them all, One disk to
On Mon, 25 Oct 2004, Osamu Aoki wrote:
I have question about handling of config.guess and config.sub in source
package. I have read autotools-dev README.Debian. So I understand these
need to be the latest ones whenever we compile the source.
Good :-)
But why in clean target? This makes
On Mon, 25 Oct 2004, Osamu Aoki wrote:
I have question about handling of config.guess and config.sub in source
package. I have read autotools-dev README.Debian. So I understand these
need to be the latest ones whenever we compile the source.
Good :-)
But why in clean target? This makes
On Sat, 02 Oct 2004, Greg Norris wrote:
On Thu, Sep 30, 2004 at 07:41:57PM +0200, martin f krafft wrote:
And its major disadvantage is that it cannot be configured per-user.
This makes bayesian filtering kinda useless.
Are there any Spamassassin based SMTP proxies which can do per-user
On Sat, 02 Oct 2004, George Danchev wrote:
Desc: Pcopy is intended to be used when doing large disk(partition) to
disk(partition) copying where dd is just too slow (and error prone).
When DD is slow, it just mean you should be using raw devices (see the raw
command)... :)
--
One disk to
On Sat, 02 Oct 2004, Stephen Gran wrote:
Does postfix not have something like exim's routers?(I really am asking
- I don't know postfix well). I was under the impression that one of
the strengths of it's modularity was that you could plug extra pieces in
in the middle of a routing chain for
On Sat, 02 Oct 2004, Greg Norris wrote:
On Thu, Sep 30, 2004 at 07:41:57PM +0200, martin f krafft wrote:
And its major disadvantage is that it cannot be configured per-user.
This makes bayesian filtering kinda useless.
Are there any Spamassassin based SMTP proxies which can do per-user
On Sat, 02 Oct 2004, George Danchev wrote:
Desc: Pcopy is intended to be used when doing large disk(partition) to
disk(partition) copying where dd is just too slow (and error prone).
When DD is slow, it just mean you should be using raw devices (see the raw
command)... :)
--
One disk to
On Sat, 02 Oct 2004, Stephen Gran wrote:
Does postfix not have something like exim's routers?(I really am asking
- I don't know postfix well). I was under the impression that one of
the strengths of it's modularity was that you could plug extra pieces in
in the middle of a routing chain for
On Fri, 01 Oct 2004, Erik Schanze wrote:
The package I try to debianize is a library, which uses autoconf.
Read the entire documents on the package autotools-dev, as well as all the
docs on the libtool package (if the lib uses libtool).
The DNMG discourages from debianize a library first.
On Fri, 01 Oct 2004, Erik Schanze wrote:
The package I try to debianize is a library, which uses autoconf.
Read the entire documents on the package autotools-dev, as well as all the
docs on the libtool package (if the lib uses libtool).
The DNMG discourages from debianize a library first.
On Thu, 18 Dec 2003, Sven Luther wrote:
I have many locales there,
[...]
Should be ok, no ?
Yes, it is correct...
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon
On Thu, 18 Dec 2003, Sven Luther wrote:
I have many locales there,
[...]
Should be ok, no ?
Yes, it is correct...
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon
On Tue, 16 Dec 2003, Sven Luther wrote:
I choose fr_FR.UTF8 or something such in gnome GDM.
And it IS just like that in your /etc/locale.gen as well? fr_FR only won't
do.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the
On Tue, 16 Dec 2003, Sven Luther wrote:
I choose fr_FR.UTF8 or something such in gnome GDM.
And it IS just like that in your /etc/locale.gen as well? fr_FR only won't
do.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the
On Thu, 20 Nov 2003, Marc A. Pelletier wrote:
Hmm; I can see how to make it work if packages register /either/ static
ordering or dependencies, but not both.
It must, for backwards compatibility. Once the package has BOTH information
registered, dependencies would take precedence (as in
Replying to myself. What a shame.
Anyway, this whole thread really belongs in debian-devel.
On Thu, 20 Nov 2003, Henrique de Moraes Holschuh wrote:
On Thu, 20 Nov 2003, Marc A. Pelletier wrote:
Hmm; I can see how to make it work if packages register /either/ static
ordering or dependencies
On Thu, 20 Nov 2003, Marc A. Pelletier wrote:
Hmm; I can see how to make it work if packages register /either/ static
ordering or dependencies, but not both.
It must, for backwards compatibility. Once the package has BOTH information
registered, dependencies would take precedence (as in
Replying to myself. What a shame.
Anyway, this whole thread really belongs in debian-devel.
On Thu, 20 Nov 2003, Henrique de Moraes Holschuh wrote:
On Thu, 20 Nov 2003, Marc A. Pelletier wrote:
Hmm; I can see how to make it work if packages register /either/ static
ordering or dependencies
On Tue, 18 Nov 2003, Marc A. Pelletier wrote:
Now /that/ is interresting and smart and is indeed likely the most promising
avenue for quick and dirty daemond integration in debian; the problem is that
from what I have understood, update-rc.d suffers from, by design, exactly the
same problem
On Tue, 18 Nov 2003, Marc A. Pelletier wrote:
Now /that/ is interresting and smart and is indeed likely the most promising
avenue for quick and dirty daemond integration in debian; the problem is that
from what I have understood, update-rc.d suffers from, by design, exactly the
same problem
On Thu, 06 Nov 2003, Zenaan Harkness wrote:
Should I email this to the debhelper script maintainer?
No. But you could send a wishlist bug to the dh_make (or debmake, whichever
one you used) pakcages to update it.
I have changed this thing in autotools-dev' README for quite a while.
The old cp
On Thu, 06 Nov 2003, Zenaan Harkness wrote:
Should I email this to the debhelper script maintainer?
No. But you could send a wishlist bug to the dh_make (or debmake, whichever
one you used) pakcages to update it.
I have changed this thing in autotools-dev' README for quite a while.
The old cp
On Thu, 06 Nov 2003, Zenaan Harkness wrote:
debhelper puts the following into the clean rule in debian/rules:
ifneq $(wildcard /usr/share/misc/config.sub)
cp -f /usr/share/misc/config.sub config.sub
endif
ifneq $(wildcard /usr/share/misc/config.guess)
cp -f
On Thu, 06 Nov 2003, Zenaan Harkness wrote:
debhelper puts the following into the clean rule in debian/rules:
ifneq $(wildcard /usr/share/misc/config.sub)
cp -f /usr/share/misc/config.sub config.sub
endif
ifneq $(wildcard /usr/share/misc/config.guess)
cp -f
On Tue, 17 Jun 2003, Johannes Rohr wrote:
as you both suggested. But I wonder if the BTS could have an invalid
tag for such cases?!?
Why clog it up with invalid reports? They stay around as closed for a small
while, then get archived...
--
One disk to rule them all, One disk to find them.
On Tue, 17 Jun 2003, Johannes Rohr wrote:
as you both suggested. But I wonder if the BTS could have an invalid
tag for such cases?!?
Why clog it up with invalid reports? They stay around as closed for a small
while, then get archived...
--
One disk to rule them all, One disk to find them.
On Mon, 16 Jun 2003, Johannes Rohr wrote:
What is the generally accepted way within the Debian culture to deal
with such reports? Do I close the bug right away? Do I downgrade it?
Do I reassign it (in this case to gstreamer)?
You can reassign it with the priority and bug title changed to
On Tue, 04 Mar 2003, Bastian Kleineidam wrote:
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
how can a package learn about its current version number?
Package information is stored in /var/lib/dpkg/available.
No. Do not skip the proper interface layers. Use dpkg to get that
On Tue, 04 Mar 2003, Bastian Kleineidam wrote:
On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote:
how can a package learn about its current version number?
Package information is stored in /var/lib/dpkg/available.
No. Do not skip the proper interface layers. Use dpkg to get that
On Sat, 01 Mar 2003, Agney Lopes Roth Ferraz wrote:
I'm looking for information about debian developer/maintainer.
http://nm.debian.org
I read in debian page that the only way to became maintainer is developing
some nice program, but I have two friends that are only who make the .deb
On Sat, 01 Mar 2003, Agney Lopes Roth Ferraz wrote:
I'm looking for information about debian developer/maintainer.
http://nm.debian.org
I read in debian page that the only way to became maintainer is developing
some nice program, but I have two friends that are only who make the .deb
On Wed, 26 Feb 2003, Volker Sturm wrote:
if I want to get into software development for Debian: Is it recommended to
stay with stable or upgrade to sid?
If you have to ask, stay with stable. You can use pbuilder to build
unstable packages.
--
One disk to rule them all, One disk to find
On Tue, 11 Feb 2003, Michael Still wrote:
I have been an open source developer for some time, and am now an
experienced Debian user (a whole week under my belt!).
Heh.
I am interested in getting some of my code available as Debian packages,
but the web pages I have been reading imply that it
On Tue, 11 Feb 2003, Michael Still wrote:
I have been an open source developer for some time, and am now an
experienced Debian user (a whole week under my belt!).
Heh.
I am interested in getting some of my code available as Debian packages,
but the web pages I have been reading imply that it
On Wed, 05 Feb 2003, Tore Anderson wrote:
* David Lloyd
I don't know if this is the right forum to ask, but I want to replace:
[EMAIL PROTECTED]:/usr/share/apps/ksplash/pics$ ls
splash_bottom.pngsplash_top.png
splash_active_bar.png
On Tue, 19 Nov 2002, Kenneth Pronovici wrote:
Should I file a bug against my own package to report the related
It's up to you...
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie.
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sat, Nov 09, 2002 at 12:06:58 -0500, Joey Hess wrote:
joey@dragon:~grep prerm =dpkg-reconfigure
foreach my $info (['prerm','upgrade', $version],
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sun, Nov 10, 2002 at 09:13:39 -0200, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
No. That's a build-dependency, you know
Hi debian-mentors!
On Sun, 10 Nov 2002, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sun, Nov 10, 2002 at 09:13:39 -0200, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
May I suggest that dh_installinit adds
On Sat, 09 Nov 2002, Martin Godisch wrote:
On Sat, Nov 09, 2002 at 08:12:57 -0200, Henrique de Moraes Holschuh wrote:
On Sat, 09 Nov 2002, Martin Godisch wrote:
dh_installinit adds 'invoke-rc.d start' (or: init.d/package start) to
postinst, hence, after dpkg-reconfigure is run, postinst
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sat, Nov 09, 2002 at 12:06:58 -0500, Joey Hess wrote:
[EMAIL PROTECTED]:~grep prerm =dpkg-reconfigure
foreach my $info (['prerm','upgrade', $version],
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sun, Nov 10, 2002 at 09:13:39 -0200, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
May I suggest that dh_installinit adds 'debconf (= 1.2.9)' to
${misc:Depends}?
No. That's a build-dependency, you know
Hi debian-mentors!
On Sun, 10 Nov 2002, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
On Sun, Nov 10, 2002 at 09:13:39 -0200, Henrique de Moraes Holschuh wrote:
On Sun, 10 Nov 2002, Martin Godisch wrote:
May I suggest that dh_installinit adds
101 - 200 of 278 matches
Mail list logo
