Bob Hilliard wrote:
Template: dict-web1913/reconf
Type: note
Description: Replace dict-web1913 with dict-gcide in /etc/dictd.conf
Is your description field really indented by one character?
--
see shy jo
Ian Duggan wrote:
When specifying the regexp to be used in a watch file, are backslashes
supposed to be escaped? The New Maintainer's Guide says one thing, but
the man page for uscan says another. Which is preferred/correct?
Install the uscan from unstable, and do not escape backslashes.
Bob Hilliard wrote:
However, after this action, /var/cache/debconf/config.dat still
contains:
Name: dict-web1913/reconf
Template: dict-web1913/reconf
Value:
Owners: unknown
echo purge | debconf-communicate
You at one point ran the config script or postinst by hand, debconf
cannot
Bob Hilliard wrote:
However, after this action, /var/cache/debconf/config.dat still
contains:
Name: dict-web1913/reconf
Template: dict-web1913/reconf
Value:
Owners: unknown
echo purge | debconf-communicate
You at one point ran the config script or postinst by hand, debconf
cannot
Robert Bihlmeyer wrote:
I maintain freenet-unstable, a free Java application that builds with
jikes, but unfortunately not with the version in unstable and testing.
I've now got a bug about that and wonder whether it should really be
serious. It's not that this package is not buildable in
Rick Younie wrote:
summary: the sbuild package has three configurations files, each
overriding the previous one: /etc/sbuild.conf, /etc/sbuild.conf.local,
~/.sbuildrc.
sbuild.conf is for upstream changes, sbuild.conf.local (a
conffile currently) for local system-wide changes, .sbuildrc for
Robert Bihlmeyer wrote:
I maintain freenet-unstable, a free Java application that builds with
jikes, but unfortunately not with the version in unstable and testing.
I've now got a bug about that and wonder whether it should really be
serious. It's not that this package is not buildable in
Rick Younie wrote:
summary: the sbuild package has three configurations files, each
overriding the previous one: /etc/sbuild.conf, /etc/sbuild.conf.local,
~/.sbuildrc.
sbuild.conf is for upstream changes, sbuild.conf.local (a
conffile currently) for local system-wide changes, .sbuildrc for
Bill Allombert wrote:
I would like to change the permission of a directory in a new
version of my package, but it seems that when you upgrade a
package, dpkg keep the old permissions on directories.
That is correct.
It is correct ? on purpose ? Where can I find a good documentation
on
Bill Allombert wrote:
I would like to change the permission of a directory in a new
version of my package, but it seems that when you upgrade a
package, dpkg keep the old permissions on directories.
That is correct.
It is correct ? on purpose ? Where can I find a good documentation
on dpkg
Duncan Findlay wrote:
I was wondering what the proper extensions for perl manpages are.
My package, spamassassin, currently installs a lot of manpages in section 3
as *.3p.gz. In perl policy, it states that this should be *.3perl.gz, but
I've also noticed a large number of packages we
Duncan Findlay wrote:
I was wondering what the proper extensions for perl manpages are.
My package, spamassassin, currently installs a lot of manpages in section 3
as *.3p.gz. In perl policy, it states that this should be *.3perl.gz, but
I've also noticed a large number of packages we
Colin Watson wrote:
It seems to me that this requirement is a relic of the times before
OpenMotif was packaged. At that point it was sensible to require
statically linked versions of Motif applications so that Debian users
could use them without having to get hold of a version of Motif
Colin Watson wrote:
It seems to me that this requirement is a relic of the times before
OpenMotif was packaged. At that point it was sensible to require
statically linked versions of Motif applications so that Debian users
could use them without having to get hold of a version of Motif
Bob Hilliard wrote:
I would like to use debconf to present a message to the admin
when a package is installed, but only if certain text does not
appear in a config file.
Without debconf, I could use code something like this in the
[post|pre]inst:
if !grep -q include
Bob Hilliard wrote:
I would like to use debconf to present a message to the admin
when a package is installed, but only if certain text does not
appear in a config file.
Without debconf, I could use code something like this in the
[post|pre]inst:
if !grep -q include
Ganesan R wrote:
This may be an obvious question. It's not enough to rename the source
tarball, I'll have to rename the sed-3.52 directory within the tarball and
create a new tarball. Is this still okay?
You don't really need to do that, there is currently no requirement
about the name of the
Tollef Fog Heen wrote:
This _will_ overwrite the local values, unless Debconf has a writable,
local DB as well. I really don't see how to implement this without a
writable DB. Is having a writable DB somewhere a requirement of
Debconf or is my code broken? If it's broken, what is the fix?
Tollef Fog Heen wrote:
This _will_ overwrite the local values, unless Debconf has a writable,
local DB as well. I really don't see how to implement this without a
writable DB. Is having a writable DB somewhere a requirement of
Debconf or is my code broken? If it's broken, what is the fix?
Adam Heath wrote:
Never build a full release from the cvs work directory. Always cvs export to
another directory first.
Doing test builds from the cvs work dir is fine. But do final releases from a
temp dir. Sometimes, the cvs work dir is poluted, and having a fresh checkout
is safer for
Peter Jay Salzman wrote:
[EMAIL PROTECTED] ls debian/
README.Debian docs pdamaze.manpagespreinst.ex
changelog ex.doc-base.package pdamaze.postinst.debhelper prerm.ex
conffiles.ex init.d.expdamaze.postrm.debhelperrules*
control
Matt Armstrong wrote:
In general, I'm confused about non-conffile stuff going in /etc.
People are used to editing whatever they want to in /etc. It seems
like if a package is going to take over a given file (e.g. an
/etc/flipit/port symlink), then it should not be in /etc but in /var
or
Matt Armstrong wrote:
In general, I'm confused about non-conffile stuff going in /etc.
People are used to editing whatever they want to in /etc. It seems
like if a package is going to take over a given file (e.g. an
/etc/flipit/port symlink), then it should not be in /etc but in /var
or
Matt Armstrong wrote:
- I really do want to make it a conffile, so the user is notified of
future options.
I don't follow this point. The user will only be informed that the
conffile has changed if they have modified it in some way and you change
the conffile that's distributed with
Russell Coker wrote:
OK. So you install a file and then customise it to the user. IMHO
customising the file on first install does not count as editing a conf file
as you are just changing what the user will see as the default config.
In your opinion mabe, but not according to policy.
Matt Armstrong wrote:
- I really do want to make it a conffile, so the user is notified of
future options.
I don't follow this point. The user will only be informed that the
conffile has changed if they have modified it in some way and you change
the conffile that's distributed with
peter karlsson wrote:
Is it possible to have different default values to a question in
different language setups?
I am trying to package a piece of software that can be installed with
two different sets of initial data, one in English and one in Swedish,
and I wish to have the English
peter karlsson wrote:
Is it possible to have different default values to a question in
different language setups?
I am trying to package a piece of software that can be installed with
two different sets of initial data, one in English and one in Swedish,
and I wish to have the English
Colin Walters wrote:
The upstream documentation comes as HTML, including the changelog. Policy
section 13.8 states that the changelog file must be compressed.
However, the changelog is hyperlinked from other parts of the
documentation; renaming it to changelog.html.gz would break those
Christian T. Steigies wrote:
main::(/usr/lib/perl/5.6.1/asm/unistd.ph:114):
114:eval 'sub __NR_iopl () { not supported;}' unless defined(__NR_iopl);
On i386, this line is:
eval 'sub __NR_iopl () {110;}' unless defined(__NR_iopl);
Hypothesis: on m68k, iopl() is not supported, or
Christian T. Steigies wrote:
#define __NR_olduname 109
#define __NR_iopl /* 110 */ not supported
#define __NR_vhangup111
#define __NR_idle /* 112 */ Obsolete
#define __NR_vm86 /* 113 */ not supported
#define __NR_wait4
Christian T. Steigies wrote:
main::(/usr/lib/perl/5.6.1/asm/unistd.ph:114):
114:eval 'sub __NR_iopl () { not supported;}' unless
defined(__NR_iopl);
On i386, this line is:
eval 'sub __NR_iopl () {110;}' unless defined(__NR_iopl);
Hypothesis: on m68k, iopl() is not supported, or
Josip Rodin wrote:
Using 'close' to close bugs, especially those which arn't really fixed but
just no longer useful, is WRONG. The submitter only gets the subject line,
and that's hardly nice. Especially when you tell people this is a dead
package, we won't help you, go find something else.
Colin Watson wrote:
But then people can't use self-compiled kernels without using
kernel-package, and you also don't know whether an installed kernel
package is the running kernel. There's no good way to do this within the
Debian packaging framework, as far as I can work out.
Well, this is
Colin Watson wrote:
But then people can't use self-compiled kernels without using
kernel-package, and you also don't know whether an installed kernel
package is the running kernel. There's no good way to do this within the
Debian packaging framework, as far as I can work out.
Well, this is
Viral wrote:
My problem is that, there will be a variable number of nodes for which
information is required. This will be only known at runtime.
No problem. A single debconf template can instantiate into an unlimited
number of individual questions. See the REGISTER command. You can also
use
Viral wrote:
My problem is that, there will be a variable number of nodes for which
information is required. This will be only known at runtime.
No problem. A single debconf template can instantiate into an unlimited
number of individual questions. See the REGISTER command. You can also
use
Alberto Gonzalez Iniesta wrote:
The problem is that /etc/multiCDrc is not a conffile yet, so making it a
conffile now won't avoid overwriting it when updating to the new version
in case it exists now. Or will it?
I think dpkg handles this ok, and compares the md5sum of the existing
file (if
Alberto Gonzalez Iniesta wrote:
The problem is that /etc/multiCDrc is not a conffile yet, so making it a
conffile now won't avoid overwriting it when updating to the new version
in case it exists now. Or will it?
I think dpkg handles this ok, and compares the md5sum of the existing
file (if
Niall Young wrote:
niall@host:~/Device-SerialPort/Device-SerialPort-0.10$ dpkg-genchanges
-fdebian/Device-SerialPort.files
dpkg-genchanges: error: badly formed line in files list file, line 1
whose contents is:
etc
etc/Device
usr
usr/lib
usr/lib/perl5
usr/lib/perl5/5.005
Niall Young wrote:
[EMAIL PROTECTED]:~/Device-SerialPort/Device-SerialPort-0.10$ dpkg-genchanges
-fdebian/Device-SerialPort.files
dpkg-genchanges: error: badly formed line in files list file, line 1
whose contents is:
etc
etc/Device
usr
usr/lib
usr/lib/perl5
usr/lib/perl5/5.005
Marc Haber wrote:
This is the way to do it for an init script. Is it OK to have a file
in /etc/default that does not provider defaults for an init script
but for an executeable called by users?
I don't know. I don't see a lot of advantage over just putting the
conffile in /etc.
There is
Marc Haber wrote:
This is the way to do it for an init script. Is it OK to have a file
in /etc/default that does not provider defaults for an init script
but for an executeable called by users?
I don't know. I don't see a lot of advantage over just putting the
conffile in /etc.
There is
Steve Langasek wrote:
/usr/share/doc/package, not /usr/share/package. Two different beasts.
Ah indeed. Then you're right of course. Sorry.
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Colin Watson wrote:
Muhammad Hussain Yusuf [EMAIL PROTECTED] wrote:
I have a package, gstar, which places various lists of stars in
/usr/share/starchart since gstar is a gtk front-end to the starchart
programme.
My question is: is there any policy or guidelines about naming stuff in
in
Julian Gilbey wrote:
Agreed. (And I don't think /usr/share/package is mandated.)
Every package MUST be accompanied by a verbatim copy of its copyright
and distribution license in the file
`/usr/share/doc/_package-name_/copyright'
Packages that are not Debian-native MUST
Steve Langasek wrote:
/usr/share/doc/package, not /usr/share/package. Two different beasts.
Ah indeed. Then you're right of course. Sorry.
--
see shy jo
Julian Gilbey wrote:
I'm currently the Maintainer of libfile-temp-perl which as of perl 5.6.1 is
included in the main Perl distribution. As the package is now redundant
should I file a bug against ftp.debian.org asking for it's removal.
Or replace it by a dummy package which says you
Julian Gilbey wrote:
I'm currently the Maintainer of libfile-temp-perl which as of perl 5.6.1 is
included in the main Perl distribution. As the package is now redundant
should I file a bug against ftp.debian.org asking for it's removal.
Or replace it by a dummy package which says you
Christian T. Steigies wrote:
I am still a little confused at what the config script does, how do I use
it when I want to use debconf in several maintainer scripts, ie preinst and
postinst? Add all db_ calls there? Does order matter? Is it a collection of
subroutines for the different texts
Christian T. Steigies wrote:
Now this is confusing like accounting, everything is inversed. I use INPUT
to OUPUT a note, ok. And I use GET to set a variable to the return value.
Once I stop trying to interprete the meaning of the commands, it actually
makes sense, like accounting...
We
Christian T. Steigies wrote:
I am still a little confused at what the config script does, how do I use
it when I want to use debconf in several maintainer scripts, ie preinst and
postinst? Add all db_ calls there? Does order matter? Is it a collection of
subroutines for the different texts and
Christian T. Steigies wrote:
Now this is confusing like accounting, everything is inversed. I use INPUT
to OUPUT a note, ok. And I use GET to set a variable to the return value.
Once I stop trying to interprete the meaning of the commands, it actually
makes sense, like accounting...
We
Rémi Perrot wrote:
I recently upload a new package called libglade-perl. After some mail
exchange with the upstream maintainer (Dermot Musgrove
[EMAIL PROTECTED]), he say that libglade-perl is not
a library and he ask me to change the name of the package to glade-perl.
He is not wrong since
Noel Koethe wrote:
Ahh, ok. So its a little problem with dh_movefiles which wants to move
from debian/tmp by default and/or ignores my export DH_COMPAT=3 in
debian/rules.
man dh_movefiles (see NOTES)
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Noel Koethe wrote:
Ahh, ok. So its a little problem with dh_movefiles which wants to move
from debian/tmp by default and/or ignores my export DH_COMPAT=3 in
debian/rules.
man dh_movefiles (see NOTES)
--
see shy jo
Eric Van Buggenhaut wrote:
It's your package. One thing you could do when you start working on it is
to remove the conflict between xabacus and xmabacus - there are better
solutions in Debian when two packages share the same file.
cu
Adrian
I'm just looking for the 'better solutions' he
Eric Van Buggenhaut wrote:
It seems the best solution indeed. Is there a way to know if a package has been
purged ? dpkg --test-purge ?
You'll have to play with dpkg -s | grep Status: I guess
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Colin Watson wrote:
Unfortunately some packages still use it; there are 68 packages in the
archive that build-depend on it. It's not clear that use of debmake can
be considered a bug unless it's actually broken.
And really quite a few more seem to use it according to the graph
somewhere on my
Eric Van Buggenhaut wrote:
It's your package. One thing you could do when you start working on it is
to remove the conflict between xabacus and xmabacus - there are better
solutions in Debian when two packages share the same file.
cu
Adrian
I'm just looking for the 'better solutions' he
Eric Van Buggenhaut wrote:
It seems the best solution indeed. Is there a way to know if a package has
been purged ? dpkg --test-purge ?
You'll have to play with dpkg -s | grep Status: I guess
--
see shy jo
Robert Bihlmeyer wrote:
Could dh_clean be extended to trap not-allowed-to-remove errors and
issue a helpful message similar to dh_testroot? Then dh_testroot could
be removed from the clean target, and it would just work for the most
common cases, and give good diagnostic for common mistakes.
Robert Bihlmeyer wrote:
Could dh_clean be extended to trap not-allowed-to-remove errors and
issue a helpful message similar to dh_testroot? Then dh_testroot could
be removed from the clean target, and it would just work for the most
common cases, and give good diagnostic for common mistakes.
Henrique M Holschuh wrote:
I wonder how strict is the about 50 characters or so limitation on the
short description for a debconf template is?
Well, you're not going to get a serious severity bug about it any time
soon.
However, debconf frontends are designed with strings of about this
length
Hamish Moffatt wrote:
A lot of packages used to test for root access in the clean target too.
That was standard practise before we had fakeroot.
I suppose when you were building as root (non-fake), you would end up
with directories owned by root, so it made sense that you would need
root
Bob Hilliard wrote:
The only guidance I can find in policy 3.5.2.0 on the subject of
stripping binaries is in section 11.1. Binaries:
Note that by default all installed binaries should be stripped, either
by using the `-s' flag to `install', or by calling `strip' on the
Colin Watson wrote:
You should not create hard links in the manual page directories, nor
put absolute filenames in .so directives.
Heh. There's a man page somewhere in debian that looks something like:
a few man header-type things here
.so /usr/bin/foo
a few man footer-type things here
Colin Watson wrote:
You should not create hard links in the manual page directories, nor
put absolute filenames in .so directives.
Heh. There's a man page somewhere in debian that looks something like:
a few man header-type things here
.so /usr/bin/foo
a few man footer-type things here
Decklin Foster wrote:
- I'm using dh_installinfo to write the install-info call into my
maintainer scripts, which produces something like:
install-info --quiet /usr/share/info/yafc.info
How do I get it to use a section? (If the answer is "file a bug on
debhelper", I'll go
Decklin Foster wrote:
- I'm using dh_installinfo to write the install-info call into my
maintainer scripts, which produces something like:
install-info --quiet /usr/share/info/yafc.info
How do I get it to use a section? (If the answer is file a bug on
debhelper, I'll go
Carlos Laviola wrote:
You're not supposed to put the manpage wherever you want to, even if it is a X
program. dh_installman puts the manpages into their respective sections, e.g.
if you have foo.1, it'll be but on section 1. If you have foo.1x, it'll be but
at /usr/X11R6/man/man1 for being in
Carlos Laviola wrote:
You're not supposed to put the manpage wherever you want to, even if it is a X
program. dh_installman puts the manpages into their respective sections, e.g.
if you have foo.1, it'll be but on section 1. If you have foo.1x, it'll be but
at /usr/X11R6/man/man1 for being in
Julian Gilbey wrote:
No, it isn't at all. Any configuration files MUST reside in /etc.
These are not configuration files (the sorts of things used to
configure a package), but score/state files, if I recall correctly.
So how about this scheme:
conffile != configuration file
There has been
Julian Gilbey wrote:
No, it isn't at all. Any configuration files MUST reside in /etc.
These are not configuration files (the sorts of things used to
configure a package), but score/state files, if I recall correctly.
So how about this scheme:
conffile != configuration file
There has been a
Manfred Wassmann wrote:
Well, um, partly so that if dh_installdocs does not do what you want,
you can work around it and still be assured of proper permissions once
you run dh_fixperms?
But if it was done in the first place dh_fixperms was not required. In
other words, it would be
Manfred Wassmann wrote:
Well, um, partly so that if dh_installdocs does not do what you want,
you can work around it and still be assured of proper permissions once
you run dh_fixperms?
But if it was done in the first place dh_fixperms was not required. In
other words, it would be
Manfred Wassmann wrote:
Well, I'm not that familiar with debhelper yet. I mistakenly assumed that
dh_installdocs would set the permissions of the installed files.
If it just copies that's nuts.
BTW I think it would be more suggestive if a command that installs doc
files would set the
Manfred Wassmann wrote:
Well, I'm not that familiar with debhelper yet. I mistakenly assumed that
dh_installdocs would set the permissions of the installed files.
If it just copies that's nuts.
BTW I think it would be more suggestive if a command that installs doc
files would set the
Manfred Wassmann wrote:
Does dh_installdocs know about this? I couldn't find anything like that in
the docs.
That's where dh_installdocs puts it. If the tool doesn't do everything
you need (and it'd be pretty hard to make debhelper handle this edge
case any better), there's nothing wrong with
Manfred Wassmann wrote:
Here is my suggestion (as I am currently in the NM-queue any comments are
greatly appreciated):
In debian/rules create a temporary doc (it should not be in the source
already) and copy the files into that directory. Then you can install the
directory with debhelper
Manfred Wassmann wrote:
Does dh_installdocs know about this? I couldn't find anything like that in
the docs.
That's where dh_installdocs puts it. If the tool doesn't do everything
you need (and it'd be pretty hard to make debhelper handle this edge
case any better), there's nothing wrong with
Jochen Voss wrote:
I have a question about debhelper:
I try to pack a package which has multiple README files,
scattered over several sub-directories.
README
foo/README
bar/README
My plan is to install them in the doc directory as
doc/README
doc/README.foo
doc/README.bar
Is
Jochen Voss wrote:
I have a question about debhelper:
I try to pack a package which has multiple README files,
scattered over several sub-directories.
README
foo/README
bar/README
My plan is to install them in the doc directory as
doc/README
doc/README.foo
doc/README.bar
Is
Joe Drew wrote:
dh_gencontrol
lxdoom creates a couple of binary packages, one of which (the svgalib binary)
is useful only on i386. Therefore, I assigned lxdoom-svga Architecture: i386
only, assuming dpkg-gencontrol would work properly with this. Apparently
not. How can I get around this
Joe Drew wrote:
dh_gencontrol
lxdoom creates a couple of binary packages, one of which (the svgalib binary)
is useful only on i386. Therefore, I assigned lxdoom-svga Architecture: i386
only, assuming dpkg-gencontrol would work properly with this. Apparently
not. How can I get around this
Domenico Andreoli wrote:
now reading the packaging manual i found this writing:
"A Conflicts entry should almost never have an `earlier than' version
clause. This would prevent dpkg from upgrading or installing the package
which declared such a conflict until the upgrade or removal of the
Domenico Andreoli wrote:
now reading the packaging manual i found this writing:
A Conflicts entry should almost never have an `earlier than' version
clause. This would prevent dpkg from upgrading or installing the package
which declared such a conflict until the upgrade or removal of the
JP Sugarbroad wrote:
I'm not sure if dpkg applies statoverrides at unpack time or after
scripts have run.
At unpack time. The preinst will have run.
--
see shy jo
JP Sugarbroad wrote:
I'm not sure if dpkg applies statoverrides at unpack time or after
scripts have run.
At unpack time. The preinst will have run.
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Drew Parsons wrote:
Anyway, I tried also using dpkg-statoverride in postinst to set the mode for
/usr/lib/games/mirrormagic, not just /var/lib... and do get the same problem:
warning: --update given but /usr/lib/games/mirrormagic does not exist
So does that mean this part of the problem is
peter karlsson wrote:
[EMAIL PROTECTED]:
Yes, just copy the commands you need into your postinst file from
/usr/share/debhelper/autoscripts/postinst-doc
Is there any way to force debhelper to insert these, rather than to insert
them manually?
It's alll explained in debhelper's
peter karlsson wrote:
[EMAIL PROTECTED]:
Yes, just copy the commands you need into your postinst file from
/usr/share/debhelper/autoscripts/postinst-doc
Is there any way to force debhelper to insert these, rather than to insert
them manually?
It's alll explained in debhelper's
Marc Haber wrote:
in sid packages, dh_suidregister is not allowed to be used any more.
However, I need my own packages mainly under potato, so I am quite
interested that they build under potato as well. Are there any
standard procedures for this, or am I left with some nasty if
constructs in
Marc Haber wrote:
I see. So I need to actually install a chrooted sid to be able to read
the manpage. That'll take a few days until I get around doing so...
Um, the man page is available in the source package, by cvs, on any one
of the debian projects machines that are running unstable, etc. I
Marc Haber wrote:
in sid packages, dh_suidregister is not allowed to be used any more.
However, I need my own packages mainly under potato, so I am quite
interested that they build under potato as well. Are there any
standard procedures for this, or am I left with some nasty if
constructs in
Marc Haber wrote:
I see. So I need to actually install a chrooted sid to be able to read
the manpage. That'll take a few days until I get around doing so...
Um, the man page is available in the source package, by cvs, on any one
of the debian projects machines that are running unstable, etc. I
Chris Hanson wrote:
I don't know the design decisions that went into debconf, but what I
am suggesting looks consistent with the design document in
/usr/share/doc/debconf/specification.txt.gz. In that document,
debconf looks very much like a database, and it seems strange that I
should need
Chris Hanson wrote:
Any reason not to do this?
Debconf is Not a Registry (TM)
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Chris Hanson wrote:
Any reason not to do this?
Debconf is Not a Registry (TM)
--
see shy jo
Francis Irving wrote:
Basically, when dh_shlibdeps runs from within dpkg-buildpackage
-rfakeroot it doesn't generate the file debian/substvars. If
I run it at the command line from the same directory, it
correctly generates the file.
You probably have some DH_COMPAT setting in your rules
201 - 300 of 419 matches
Mail list logo
