On Sat, 05 May 2001, Wolfgang Sourdeau wrote:
I am currently packaging gfax. In the Debian Policy it is specified
that one, willing to divert an executable, should contact the original
executable's maintainer.
This is there mainly to make sure you damn well know what you're doing when
playing
On Sat, 05 May 2001, Colin Watson wrote:
Is this some kind of insurance against problems in the upgrade? When you
Yes. I think most of the packages I've seen that use diversions do not
remove them in prerm, but rather in postrm purge. I'm not sure¸ though.
Still, as long as diversions are
On Sat, 05 May 2001, Wolfgang Sourdeau wrote:
I am currently packaging gfax. In the Debian Policy it is specified
that one, willing to divert an executable, should contact the original
executable's maintainer.
This is there mainly to make sure you damn well know what you're doing when
playing
On Sat, 05 May 2001, Colin Watson wrote:
Is this some kind of insurance against problems in the upgrade? When you
Yes. I think most of the packages I've seen that use diversions do not
remove them in prerm, but rather in postrm purge. I'm not sure¸ though.
Still, as long as diversions are never
On Fri, 04 May 2001, Warren Stramiello wrote:
Sorry, didn't clarify. I should package the library for non-free and the
bet for contrib, correct?
Yes.
--
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
On Fri, 04 May 2001, Warren Stramiello wrote:
Sorry, didn't clarify. I should package the library for non-free and the
bet for contrib, correct?
Yes.
--
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
On Thu, 03 May 2001, [EMAIL PROTECTED] wrote:
I posted an ITP: ardour -- a Linux Digital Audio Workstation (bug #95870).
Sadly enough, upstream author doesn't seem to agree on me doing this.
What can you advice me to do ? Should I try to convince him ? Or package it
anyway ?
You could offer
On Thu, 03 May 2001, [EMAIL PROTECTED] wrote:
I posted an ITP: ardour -- a Linux Digital Audio Workstation (bug #95870).
Sadly enough, upstream author doesn't seem to agree on me doing this.
What can you advice me to do ? Should I try to convince him ? Or package it
anyway ?
You could offer
Hello fellow developers,
I wonder how strict is the about 50 characters or so limitation on the
short description for a debconf template is?
I ask this because some translators seem to be fond of tacking long things
in there. This has happened to some fetchmail templates, for example.
Should
Hello fellow developers,
I wonder how strict is the about 50 characters or so limitation on the
short description for a debconf template is?
I ask this because some translators seem to be fond of tacking long things
in there. This has happened to some fetchmail templates, for example.
Should I
On Mon, 30 Apr 2001, Santiago Vila wrote:
James Troup wrote:
The canonical source for the debian keyring _is_[2] kerying.debian.org
(via anon-rsync); period. The package is a convenience, nothing
more[3].
A package which is horribly outdated is everything but a convenience.
That, I
On Mon, 30 Apr 2001, Santiago Vila wrote:
James Troup wrote:
The canonical source for the debian keyring _is_[2] kerying.debian.org
(via anon-rsync); period. The package is a convenience, nothing
more[3].
A package which is horribly outdated is everything but a convenience.
That, I
On Thu, 26 Apr 2001, Wolfgang Sourdeau wrote:
paragraph 6.4.1 it is mentionned that the archive maintainer will
chose the appropriate category for a package. Does this mean that one
should take arrangement with him before uploading the package (so as
Most just peruse the archive, find the
On Thu, 26 Apr 2001, Wolfgang Sourdeau wrote:
paragraph 6.4.1 it is mentionned that the archive maintainer will
chose the appropriate category for a package. Does this mean that one
should take arrangement with him before uploading the package (so as
Most just peruse the archive, find the
On Tue, 17 Apr 2001, Marc Haber wrote:
the policy upgrading checklist says:
| - Files in /usr/share/doc may not be referenced by any
|program. If such files are needed, they must be placed in
|/usr/share/package-name/, and symbolic links created as required
|in
On Tue, 17 Apr 2001, Marc Haber wrote:
I have a package where the init script contains most of the package's
functionality, and parses a free-format config file
/etc/$PACKAGE.conf. That file is not a shell script and can't be
directly sourced.
Can I keep that file as /etc/$PACKAGE, should I
On Tue, 17 Apr 2001, Marc Haber wrote:
the policy upgrading checklist says:
| - Files in /usr/share/doc may not be referenced by any
|program. If such files are needed, they must be placed in
|/usr/share/package-name/, and symbolic links created as required
|in
On Tue, 10 Apr 2001, Carlos Prados Bocos wrote:
But I have only received confirmation of the installation of towitoko, and
not of pcsc-lite.
I only wanted to know if this is normal, or it means that there is
something wrong with the second package. In this case, where should I
check if
On Tue, 27 Mar 2001, Steve Langasek wrote:
build time. For questions of maintenance and bandwidth, I've chosen not to
include the Samba source in the tarball; I find that automatically downloading
I'm facing the same problem. I have a binary-all data package that is 26MB
in size. I am not
On Tue, 06 Mar 2001, Martin Bialasinski wrote:
* Steve M Robbins [EMAIL PROTECTED] wrote:
What I am proposing is a source package that generates *both* a
"main" and a "contrib" .deb.
This is not allowed.
Or rather, it is... kinda. You can have your source package generate two
sets of
On Tue, 06 Mar 2001, Steve M. Robbins wrote:
On Tue, Mar 06, 2001 at 06:54:31PM -0300, Henrique M Holschuh wrote:
You gain nothing in upload time, but it certains give you less hassle to
only have one single source tree in CVS, for example.
Yeah, it's a cute hack.
Too bad
On Tue, 06 Mar 2001, Martin Bialasinski wrote:
* Steve M Robbins [EMAIL PROTECTED] wrote:
What I am proposing is a source package that generates *both* a
main and a contrib .deb.
This is not allowed.
Or rather, it is... kinda. You can have your source package generate two
sets of .debs
On Tue, 06 Mar 2001, Steve M. Robbins wrote:
On Tue, Mar 06, 2001 at 06:54:31PM -0300, Henrique M Holschuh wrote:
You gain nothing in upload time, but it certains give you less hassle to
only have one single source tree in CVS, for example.
Yeah, it's a cute hack.
Too bad
On Sun, 25 Feb 2001, Sam TH wrote:
Well, sort of. For the packe in question, it does. But say there was
a package that depended on both GLib and GNOME (say, by including
If your package directly depends on another, declare it. The depends that
are to be left 'implicit' are those of the
On Sun, 25 Feb 2001, Eric Van Buggenhaut wrote:
Perhaps better: copy it in the postinst, remove the old version in the
postinst. Then if any problems arise, the original version will still
be present.
BAD idea. This will defeat the conffile change detection engine in dpkg, and
On Sun, 25 Feb 2001, Sam TH wrote:
Well, sort of. For the packe in question, it does. But say there was
a package that depended on both GLib and GNOME (say, by including
If your package directly depends on another, declare it. The depends that
are to be left 'implicit' are those of the
On Sun, 25 Feb 2001, Eric Van Buggenhaut wrote:
Perhaps better: copy it in the postinst, remove the old version in the
postinst. Then if any problems arise, the original version will still
be present.
BAD idea. This will defeat the conffile change detection engine in dpkg, and
will
On Sun, 25 Feb 2001, Julian Gilbey wrote:
On Fri, Feb 23, 2001 at 03:57:33PM -0800, Sean 'Shaleh' Perry wrote:
in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and
Perhaps better: copy it in the postinst, remove the old version in the
postinst. Then if any problems
On Sun, 25 Feb 2001, Julian Gilbey wrote:
On Fri, Feb 23, 2001 at 03:57:33PM -0800, Sean 'Shaleh' Perry wrote:
in your preinst, check for /etc/foo and if it exists, mkdir /etc/package and
Perhaps better: copy it in the postinst, remove the old version in the
postinst. Then if any problems
On Sun, 25 Feb 2001, Julian Gilbey wrote:
On Sat, Feb 24, 2001 at 10:42:38PM -0300, Henrique M Holschuh wrote:
Yes, that might be a good idea. However, as a rule of thumb, downgrading is
not supported (do note that failed/aborted upgrades ARE supported).
It isn't? I thought we tried
On Mon, 12 Feb 2001, Michael-John Turner wrote:
Does anyone know of any packages that have been updated to use
dpkg-statoverride for managing suid/sgid binaries owned by users created
during the package's postinst? I'm looking for the 'correct' way of
Yes, package fcron needs to do this.
On Mon, 12 Feb 2001, Michael-John Turner wrote:
Does anyone know of any packages that have been updated to use
dpkg-statoverride for managing suid/sgid binaries owned by users created
during the package's postinst? I'm looking for the 'correct' way of
Yes, package fcron needs to do this.
On Thu, 08 Feb 2001, Adam C Powell IV wrote:
I'd blame tar or the MIPS port, but that he reproduced on i386 completely
baffles me...
See http://bugs.debian.org/84829
Well, IMHO, if the md5sums are OK in his side as the bug report states, and
tar still fails to unpack, he must have somehow
On Thu, 08 Feb 2001, Adam C Powell IV wrote:
I'd blame tar or the MIPS port, but that he reproduced on i386 completely
baffles me...
See http://bugs.debian.org/84829
Well, IMHO, if the md5sums are OK in his side as the bug report states, and
tar still fails to unpack, he must have somehow
On Fri, 26 Jan 2001, Junichi Uekawa wrote:
In Thu, 25 Jan 2001 19:29:21 +0100 Josip Rodin [EMAIL PROTECTED] cum veritate
scripsit :
There's no public access to non-US Incoming AFAIR. Anyway, you should
get a
REJECT email from dinstall if the package gets rejected and you're
listed as
On Fri, 26 Jan 2001, Junichi Uekawa wrote:
In Thu, 25 Jan 2001 19:29:21 +0100 Josip Rodin [EMAIL PROTECTED] cum
veritate scripsit :
There's no public access to non-US Incoming AFAIR. Anyway, you should
get a
REJECT email from dinstall if the package gets rejected and you're
listed as
On Sun, 21 Jan 2001, [EMAIL PROTECTED] wrote:
I know I want a xgospel_1.12-4.deb and xgospel_1.12-4.dsc
I have been employed as a unix sysadmin and much more recently, perl
programmer (and even more recently, my first C project)
And I have time.
Well, download the required packages to
On Mon, 22 Jan 2001, Chris Hanson wrote:
Chris Hanson wrote:
Any reason not to do this?
Debconf is Not a Registry (TM)
I second that. Do *NOT* use Debconf as a registry. That is EVIL. Do not do
it.
That doesn't sound like a reason; it sounds more like an axiom. Care
It is
On Sun, 21 Jan 2001, [EMAIL PROTECTED] wrote:
I know I want a xgospel_1.12-4.deb and xgospel_1.12-4.dsc
I have been employed as a unix sysadmin and much more recently, perl
programmer (and even more recently, my first C project)
And I have time.
Well, download the required packages to
On Mon, 22 Jan 2001, Chris Hanson wrote:
Chris Hanson wrote:
Any reason not to do this?
Debconf is Not a Registry (TM)
I second that. Do *NOT* use Debconf as a registry. That is EVIL. Do not do
it.
That doesn't sound like a reason; it sounds more like an axiom. Care
It is
On Fri, 12 Jan 2001, Brian Russo wrote:
I know you're not (unless w/permission, submitter, or maintainer, etc)
supposed to close bugs.. but what about things like changing subjects..
merging.. changing severity levels..
QA work in the BTS, helping triage, classify and tag bugs is usually
On Fri, 12 Jan 2001, Brian Russo wrote:
I know you're not (unless w/permission, submitter, or maintainer, etc)
supposed to close bugs.. but what about things like changing subjects..
merging.. changing severity levels..
QA work in the BTS, helping triage, classify and tag bugs is usually
This is just a small list of points to keep in mind...
1. Be careful with upload queues. If you use an upload queue, the packages
are moved to ftp-master using someone else's userid. This means you cannot
overwrite them or remove them from ftp-master's incoming either, as the
queue daemon
This is just a small list of points to keep in mind...
1. Be careful with upload queues. If you use an upload queue, the packages
are moved to ftp-master using someone else's userid. This means you cannot
overwrite them or remove them from ftp-master's incoming either, as the
queue daemon refuses
On Mon, 11 Dec 2000, Jeremy Higgs wrote:
The deb package seems to be fixed in terms of the firewall init.d
script and it's removal and install behaviour, but I can't seem to
get file permissions working!
dh_fixperms changes them. You should force the non-standard permissions you
need after
On Sat, 09 Dec 2000, Karl M. Hegbloom wrote:
[ObCrossposts: We should decide what list to discuss this on.]
Please do so in debian-policy (reply-to: set). The BTS bug number for this
problem is 79210.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and
On Sat, 09 Dec 2000, Hamish Moffatt wrote:
On Fri, Dec 08, 2000 at 11:33:05PM -0200, Henrique M Holschuh wrote:
Should I be filling a wishlist bug against lintian, or is it ok (although
not optimal) to have .orig.tar.gz files unpacking at foo-1.2.3 instead of
foo-1.2.3.orig ?
The tools
On Sat, 09 Dec 2000, Karl M. Hegbloom wrote:
[ObCrossposts: We should decide what list to discuss this on.]
Please do so in debian-policy (reply-to: set). The BTS bug number for this
problem is 79210.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and
Hello,
I was playing around with cvs-buildpackage today (*very* slick set of tools,
I'm going to send Manoj a thank you note for this one. Heck, if I lived
anywhere near him, I'd pay him a insert Manoj's beverage of choice here
:-) ), and noticed that my source .orig.tar.gz were a bit bogus:
Hello,
I was playing around with cvs-buildpackage today (*very* slick set of tools,
I'm going to send Manoj a thank you note for this one. Heck, if I lived
anywhere near him, I'd pay him a insert Manoj's beverage of choice here
:-) ), and noticed that my source .orig.tar.gz were a bit bogus:
On Sat, 25 Nov 2000, Steve Dobson wrote:
The make files use LD_LIBRARY_PATH to pick up the libraries that have just been
built.
However, as I run `debuild -rsudo', the LD_LIBRARY_PATH is of course ignored as the
building is being performed as root (why? -- isn't this a bug?), and the
On Sat, 25 Nov 2000, Steve Dobson wrote:
The make files use LD_LIBRARY_PATH to pick up the libraries that have just
been built.
However, as I run `debuild -rsudo', the LD_LIBRARY_PATH is of course ignored
as the
building is being performed as root (why? -- isn't this a bug?), and the
On Sat, 25 Nov 2000, Henrique M Holschuh wrote:
trick for me for a while. Try it before filing the bug, because one would
have to code a lot of stuff to get around the need to build .debs as a
normal user (i.e.: non-root and not under fakeroot) AFAIK.
Erk. I'm not fully awake yet, it seems. I
53 matches
Mail list logo
