Frank Küster wrote:
- If a debconf question is manipulated by db_set, does that affect its
seen flag? And if it does, does it take effect immediately (i.e.,
also for a following db_inut ...), or only in the next run of the
config file?
No, you would have to use FSET to manipulate a
Eduard Bloch wrote:
However, a possible implementation failed completely because of
stupideness of svn merge. So we have to find an alternative solution
with diffpatchcp. OTOH it is not possible to keep the version history of
every file.
I think you're looking for svn_load_dirs.
--
see shy
Fabian Fagerholm wrote:
Thanks to [EMAIL PROTECTED] and [EMAIL PROTECTED] for their
insight into this issue. I will try to summarize everything in this
reply to myself.
Nice job writing this up, here are some corrections.
The repository will have the following structure:
trunk/
Jamin W. Collins wrote:
I was with you up to this point. I don't normally name my working copy
in the form project-version as that form is needed for actually making
hte package and for that we need an exported copy of the working copy.
Actually, dpkg-buildpackage does not care what you name
Jamin W. Collins wrote:
I prefer an alternate structure where you start with the project as a
top level. This keeps all project (package) related files under one
directory in the project:
project/
trunk/
branches/
tags/
vendor/
The only problem with this
Fabian Fagerholm wrote:
Thanks to [EMAIL PROTECTED] and [EMAIL PROTECTED] for their
insight into this issue. I will try to summarize everything in this
reply to myself.
Nice job writing this up, here are some corrections.
The repository will have the following structure:
trunk/
Jamin W. Collins wrote:
I was with you up to this point. I don't normally name my working copy
in the form project-version as that form is needed for actually making
hte package and for that we need an exported copy of the working copy.
Actually, dpkg-buildpackage does not care what you name
Tommaso Moroni wrote:
I'm packaging for the first time a perl program and I have some doubts about
dh-perl.
The program contains those lines:
use DBI;
use HTML::Template;
but dh-perl doesn't find any dependency, so I added manually
libhtml-template-perl and libdbd-pg-perl in the
Tommaso Moroni wrote:
I'm packaging for the first time a perl program and I have some doubts about
dh-perl.
The program contains those lines:
use DBI;
use HTML::Template;
but dh-perl doesn't find any dependency, so I added manually
libhtml-template-perl and libdbd-pg-perl in the
Kenneth Pronovici wrote:
Anyway, now that I've done all of this cleanup, I've realized that the
package won't move into testing until I build it on all of the
architectures it was built on for woody. Right now, according to the
excuses list, I am missing alpha, arm, hppa, ia64, powerpc, s390
Kenneth Pronovici wrote:
Anyway, now that I've done all of this cleanup, I've realized that the
package won't move into testing until I build it on all of the
architectures it was built on for woody. Right now, according to the
excuses list, I am missing alpha, arm, hppa, ia64, powerpc, s390
Marc Haber wrote:
I am currently preparing packages for rrfw (see bug#186828). The
daemons that come with rrfw run as user rrfw, and the Makefiles of
that package insist on chowning some files to rrfw at build time. That
- of course - fails when the rrfw account does not exist at build
time.
Marc Haber wrote:
I am currently preparing packages for rrfw (see bug#186828). The
daemons that come with rrfw run as user rrfw, and the Makefiles of
that package insist on chowning some files to rrfw at build time. That
- of course - fails when the rrfw account does not exist at build
time.
I really think this should go to the debian-perl list so I'm sending it
there. The libc-include-perl example below is one of the best arguments
I've seen for changing the perl module naming scheme. It's a pity that
we didn't think it through more before deciding on it. IIRC we just took
the
, download($bug));
+ }
+
+}
+
# Add any new commands here.
=item version
@@ -325,7 +431,7 @@
sub bts_version {
(my $progname = $0) =~ s%.*/%%;
print STDOUT $progname version $version\n;
-print STDOUT Copyright (C) 2001 by Joey Hess [EMAIL PROTECTED].\n;
+print
I really think this should go to the debian-perl list so I'm sending it
there. The libc-include-perl example below is one of the best arguments
I've seen for changing the perl module naming scheme. It's a pity that
we didn't think it through more before deciding on it. IIRC we just took
the
, download($bug));
+ }
+
+}
+
# Add any new commands here.
=item version
@@ -325,7 +431,7 @@
sub bts_version {
(my $progname = $0) =~ s%.*/%%;
print STDOUT $progname version $version\n;
-print STDOUT Copyright (C) 2001 by Joey Hess [EMAIL PROTECTED].\n;
+print
Mike Schacht wrote:
I am not an official debian developer, but I maintain a couple of
packages. One of them, kdirstat, is already in the official
distribution. I intend to apply as a NM soon, but in the meantime,
since the last update of kdirstat, I am having portability problems. I
have
Jonas Meurer wrote:
On 16/05/2003 Joe Nahmias wrote:
if dpkg --compare-versions $3 = 0.1g
then
db_input high lurker/upgrade01_info || true
db_go
elif dpkg --compare-versions $3 = 0.5
then
John Lightsey wrote:
Following the advice given on Debian Mentors I've started going through the
various bug lists looking for reproducable, isolated and fixable bugs to help
out with. In the process I've become fairly comfortable with reportbug but
I've also come up with a few questions
Frank Küster wrote:
Hi,
the developers' reference says in 6.4:
| Standard input and output may be redirected (e.g. into pipes) for
| logging purposes, so don't rely on them being a tty.
So far, so good. But is it o.k. if the script itself performs
redirections? For example something
Bill Allombert wrote:
What is the best way to handle native Debian packages under CVS?
The problem is to avoid the CVS directories going in the tarball.
The clean way is build from an exported tree using cvs-buildpackage.
AFAIK it works the same for native as for non-native packages.
The
Frank Küster wrote:
then debconf-show netenv says nothing, i.e. all the debconf items should
be purged from the database
Try 'debconf-how unknown'
And now it is back. Is it possible that the problem comes from my
testing of the scripts? Since the config script got fairly complex, I
have
Frank Küster wrote:
then debconf-show netenv says nothing, i.e. all the debconf items should
be purged from the database
Try 'debconf-how unknown'
And now it is back. Is it possible that the problem comes from my
testing of the scripts? Since the config script got fairly complex, I
have
Matthew Danish wrote:
If you don't learn, you're going to make the same mistakes that were
made before.
Making mistakes can be the essence of learning. I've written spaghetti
code in BASIC, I've written C with buffer overflows, I've written
accidential rm -rf's in shell. I've written bubble
Matthew Danish wrote:
If you don't learn, you're going to make the same mistakes that were
made before.
Making mistakes can be the essence of learning. I've written spaghetti
code in BASIC, I've written C with buffer overflows, I've written
accidential rm -rf's in shell. I've written bubble
I get less out of computer books than most people on this thread. With
the technical/reference books I seem to not read them until I know most
of what's in them, and then just use them to mop up any odd corner I
missed. And I'd rather learn the more process and theory oriented stuff
the hard way.
Bastian Kleineidam wrote:
Hmm, dh_make is trying to do a similar approach. Why not use that way?
I like to have the original .tar.gz exactly as I downloaded it. dh_make
unpacks the source and repacks it to a new .orig.tar.gz.
Why would dh_make go out of its way to violate best practices like
Steve Kemp wrote:
As an aside I wonder how well SE-Linux, or the other improved
security patches handle installation issues? I know that by installing
a random package you're effectively giving the package maintainer
root upon your box.
I'd imagine that a package installation
Bastian Kleineidam wrote:
Hmm, dh_make is trying to do a similar approach. Why not use that way?
I like to have the original .tar.gz exactly as I downloaded it. dh_make
unpacks the source and repacks it to a new .orig.tar.gz.
Why would dh_make go out of its way to violate best practices like
Steve Kemp wrote:
As an aside I wonder how well SE-Linux, or the other improved
security patches handle installation issues? I know that by installing
a random package you're effectively giving the package maintainer
root upon your box.
I'd imagine that a package installation
Joshua Kwan wrote:
Using DH_COMPAT=2 in my rules and calling dh_shlibdeps -a.. however, it
does nothing! It creates a single substvars file if DH_COMPAT is unset.
The first thing to do is show us what it says in verbose mode with -v.
At a guess you may not have any elf binaries installed
Joshua Kwan wrote:
Using DH_COMPAT=2 in my rules and calling dh_shlibdeps -a.. however, it
does nothing! It creates a single substvars file if DH_COMPAT is unset.
The first thing to do is show us what it says in verbose mode with -v.
At a guess you may not have any elf binaries installed
sean finney wrote:
currently, there's a file /etc/sugarplum/apache.conf that has the
rewrite rules, including the location of /sugarplum. if i were to do
one of the above suggestions, what's the best way to handle this file?
would it still be as a conffile, even though every time the package
sean finney wrote:
currently, there's a file /etc/sugarplum/apache.conf that has the
rewrite rules, including the location of /sugarplum. if i were to do
one of the above suggestions, what's the best way to handle this file?
would it still be as a conffile, even though every time the package
Daniel Ruoso wrote:
as I can see, this is a recurrent question (I've made the same question
a year ago). I have a proposal:
As debmake and dh-make are the two mostly used helper scripts, I propose
the creation of a document to be available at
http://www.debian.org/devel explaining about
Daniel Ruoso wrote:
as I can see, this is a recurrent question (I've made the same question
a year ago). I have a proposal:
As debmake and dh-make are the two mostly used helper scripts, I propose
the creation of a document to be available at
http://www.debian.org/devel explaining about
Colin Watson wrote:
I would use the various introspection-related modules to do this (maybe
Devel::Symdump or B?), but it's not possible to get it reliably correct
automatically. I think there are plenty of not-particularly-pathological
scripts and modules in the distribution that would easily
Steve Kemp wrote:
Mapping from a perl module to a Debian package should be trivial,
I would have thought.
Given the system upon which dh_perl would be run would have the
modules installed it should be a simple matter of running
'dpkg --search path/to/perl/module.pm' - or am I missing
pp wrote:
I have some problems with debconf:
Can't call method clearall on an undefined value at
/usr/share/perl5/Debconf/Template.pm line 150, GEN0 chunk 1.
Any idea? I can not build package cause of this error.
I'd need a copy of your debconf database and a log of you reproducing
the
pp wrote:
I have some problems with debconf:
Can't call method clearall on an undefined value at
/usr/share/perl5/Debconf/Template.pm line 150, GEN0 chunk 1.
Any idea? I can not build package cause of this error.
I'd need a copy of your debconf database and a log of you reproducing
the
Turbo Fredriksson wrote:
I've setup a new SPARC where I will do some SPARC development and
testing of my own packages. But I'm getting an error from dh_clean
(see subject)!
I suppose that there is a Debian::Debhelper::Dh_Lib module somewhere on
your perl @INC that is very old and not shipped
Turbo Fredriksson wrote:
I've setup a new SPARC where I will do some SPARC development and
testing of my own packages. But I'm getting an error from dh_clean
(see subject)!
I suppose that there is a Debian::Debhelper::Dh_Lib module somewhere on
your perl @INC that is very old and not shipped
Ross Boylan wrote:
If it is held again in San Francisco (economy, tech market, etc) I usually
take charge of the booth here. As the time comes closer we discuss
somethings here and on a Bay Area mailing list.
I'm in San Francisco, and this is the first I've heard about a Bay Area
list.
Ross Boylan wrote:
If it is held again in San Francisco (economy, tech market, etc) I usually
take charge of the booth here. As the time comes closer we discuss
somethings here and on a Bay Area mailing list.
I'm in San Francisco, and this is the first I've heard about a Bay Area
list.
Martin Godisch wrote:
Since debconf 1.2.9 dpkg-reconfigure calls prerm, which does invoke-rc.d
stop, so I think this would be the correct runtime dependency when
dpkg-reconfigure has to stop a daemon before it can be (re)started in
postinst...
I don't see what you mean, and this seems to have
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
${misc:Depends}?
Whatever
Martin Godisch wrote:
Since debconf 1.2.9 dpkg-reconfigure calls prerm, which does invoke-rc.d
stop, so I think this would be the correct runtime dependency when
dpkg-reconfigure has to stop a daemon before it can be (re)started in
postinst...
I don't see what you mean, and this seems to have
Martin Godisch wrote:
dh_installinit adds 'invoke-rc.d start' (or: init.d/package start) to
postinst, hence, after dpkg-reconfigure is run, postinst will try to
start an already running service, start-stop-daemon will fail, and the
daemon will not reload its new configuration.
What's the
Martin Godisch wrote:
I do not upgrade, dpkg-reconfigure doesn't call prerm...
Look again.
joeydragon:~grep prerm =dpkg-reconfigure
foreach my $info (['prerm','upgrade', $version],
--
see shy jo
msg07790/pgp0.pgp
Description: PGP signature
Martin Godisch wrote:
dh_installinit adds 'invoke-rc.d start' (or: init.d/package start) to
postinst, hence, after dpkg-reconfigure is run, postinst will try to
start an already running service, start-stop-daemon will fail, and the
daemon will not reload its new configuration.
What's the
Martin Godisch wrote:
I do not upgrade, dpkg-reconfigure doesn't call prerm...
Look again.
[EMAIL PROTECTED]:~grep prerm =dpkg-reconfigure
foreach my $info (['prerm','upgrade', $version],
--
see shy jo
pgp58jOS4Ok1X.pgp
Description: PGP signature
Brian Nelson wrote:
I have a prospective package that checks for the environment variable
DPKG_RECONFIGURE=1 in the postinst, and if it decides that it's being
reconfigured, it will overwrite its configuration file (not a conffile)
based on the debconf answers. The theory is that if a user
Brian Nelson wrote:
I have a prospective package that checks for the environment variable
DPKG_RECONFIGURE=1 in the postinst, and if it decides that it's being
reconfigured, it will overwrite its configuration file (not a conffile)
based on the debconf answers. The theory is that if a user
Sven Luther wrote:
I created a templates file, put it in the debian directory, created a
config file and a postinst file, like was adviced.
Now, the package builds fine, i tried running the postinst by hand, and
it asked me the question in the template. When i installed the built
package,
Sven Luther wrote:
Maybe this should be more proeminently said in
/usr/share/doc/debconf-doc/tutorial.txt.gz, no, there is only a quick
mention about installing in debian/tmp/DEBIAN/, which i missed, and the
fact that the newline cut this path in two did not help. Also maybe the
note about
Sven Luther wrote:
I created a templates file, put it in the debian directory, created a
config file and a postinst file, like was adviced.
Now, the package builds fine, i tried running the postinst by hand, and
it asked me the question in the template. When i installed the built
package,
Sven Luther wrote:
Maybe this should be more proeminently said in
/usr/share/doc/debconf-doc/tutorial.txt.gz, no, there is only a quick
mention about installing in debian/tmp/DEBIAN/, which i missed, and the
fact that the newline cut this path in two did not help. Also maybe the
note about
Sven LUTHER wrote:
Since the bytecode executables are arch independent, i think it would be
nice to build them arch: all, since this would mean, apart from smaller
sized packages, also that we don't have 12+ version of the same thing in
the archive (well, at least we can spare all the arches
Sven LUTHER wrote:
Well, what about the coq for example, which is 7 MB package (on i386, so
maybe it is bigger for other arches) and 20MB installed.
I guess it's on the line.
There is also the buildd resources, especially on the slower
arches. I guess it takes much time to build coq on m68k
Sven LUTHER wrote:
Since the bytecode executables are arch independent, i think it would be
nice to build them arch: all, since this would mean, apart from smaller
sized packages, also that we don't have 12+ version of the same thing in
the archive (well, at least we can spare all the arches
Matthias Urlichs wrote:
IMHO it's a good reason for not mixing configuration with execution,
and it's an even better reason for fixing a bug in DebConf. Specifically,
setting the Close-On-Exec flag on the file descriptor(s) which represent
the DebConf protocol will prevent all these problems
Matthias Urlichs wrote:
IMHO it's a good reason for not mixing configuration with execution,
and it's an even better reason for fixing a bug in DebConf. Specifically,
setting the Close-On-Exec flag on the file descriptor(s) which represent
the DebConf protocol will prevent all these problems
Bas Zoetekouw wrote:
SPAM: * 4.5 -- RBL: Received via a relay in bl.spamcop.net
SPAM: [RBL check: found 214.224.20.195.bl.spamcop.net.]
That score should probably be reduced to, oh, 1 or so, given what I've
heard about spamcop's propensity for flagging things like legit list serv
Bas Zoetekouw wrote:
SPAM: * 4.5 -- RBL: Received via a relay in bl.spamcop.net
SPAM: [RBL check: found 214.224.20.195.bl.spamcop.net.]
That score should probably be reduced to, oh, 1 or so, given what I've
heard about spamcop's propensity for flagging things like legit list serv
I've tried the solution proposed by Joey (using the .TH field in the
man source), but it didn't work... so I think the only way is to do
it manually as many of you have suggested.
Oh hmm, I'd forgotten that the .TH line typically has the man page name
in all upper-case, which means there is
I've tried the solution proposed by Joey (using the .TH field in the
man source), but it didn't work... so I think the only way is to do
it manually as many of you have suggested.
Oh hmm, I'd forgotten that the .TH line typically has the man page name
in all upper-case, which means there is
Drew Parsons wrote:
I'm getting an error from dh_builddeb when trying to build a new package.
The build was working previously, but today it started failing, and doesn't
really say why. Are there any known problem with dh_builddeb?
No. It is a very thin wrapper around dpkg --build
So
Marco Presi wrote:
My problem is this: for the two packeges I want to have two
different man pages (in fact server-enhanced has more config
options that server) but it would nice if the man pages could have
the same name (server.conf.5)
I don't know how to resolve this,
Drew Parsons wrote:
I'm getting an error from dh_builddeb when trying to build a new package.
The build was working previously, but today it started failing, and doesn't
really say why. Are there any known problem with dh_builddeb?
No. It is a very thin wrapper around dpkg --build
So
Marco Presi wrote:
My problem is this: for the two packeges I want to have two
different man pages (in fact server-enhanced has more config
options that server) but it would nice if the man pages could have
the same name (server.conf.5)
I don't know how to resolve this,
Devin Carraway wrote:
This is a small Perl module I had need of during a recent project at
work, but which wasn't in Debian.
Essentially it provides the comparison indicating that (e.g.)
2.10.1pl1-8 is greater than 2.9.8.1-4. Small, simple, perl-only.
Packages may be had from
Devin Carraway wrote:
This is a small Perl module I had need of during a recent project at
work, but which wasn't in Debian.
Essentially it provides the comparison indicating that (e.g.)
2.10.1pl1-8 is greater than 2.9.8.1-4. Small, simple, perl-only.
Packages may be had from
Jérôme Marant wrote:
I need to merge the wwsympa package into sympa. Both packages
use debconf.
I wonder how I should merge wwsympa debconf templates into sympa's.
In sympa, debconf variables start with sympa/ and wwsympa ones
start with wwsympa/
If I keep the same variable
Jérôme Marant wrote:
I need to merge the wwsympa package into sympa. Both packages
use debconf.
I wonder how I should merge wwsympa debconf templates into sympa's.
In sympa, debconf variables start with sympa/ and wwsympa ones
start with wwsympa/
If I keep the same variable name,
Eric Van Buggenhaut wrote:
I don't agree with you here. When you have games that use high scores
files, these are placed in /var as per FHS 5.4
(http://www.debian.org/doc/packaging-manuals/fhs/fhs-5.4.html) and
obvioulsy tagged as conffiles (you don't want to lose your
high scores files when
Eric Van Buggenhaut wrote:
I don't agree with you here. When you have games that use high scores
files, these are placed in /var as per FHS 5.4
(http://www.debian.org/doc/packaging-manuals/fhs/fhs-5.4.html) and
obvioulsy tagged as conffiles (you don't want to lose your
high scores files when
Michael Cardenas wrote:
I'm working on the limewire deb package, and the developer has asked
me to do something that I'm sure users are not going to want.
Limewire displays small banner ads in the bottom of the application
window, and there's a boolean which turns this on. When you get the
Michael Cardenas wrote:
I'm working on the limewire deb package, and the developer has asked
me to do something that I'm sure users are not going to want.
Limewire displays small banner ads in the bottom of the application
window, and there's a boolean which turns this on. When you get the
Oliver Kurth wrote:
Hello!
I want to package cpuburn, this is a small collection of assembler
prgrams to test CPUs (x86 only). lintian gives me these errors:
oku@robin:~/debian/cpuburn-1.4$ lintian ../cpuburn_1.4-1_i386.deb
E: cpuburn: statically-linked-binary ./usr/sbin/burnBX
I belive
Oliver Kurth wrote:
Hello!
I want to package cpuburn, this is a small collection of assembler
prgrams to test CPUs (x86 only). lintian gives me these errors:
[EMAIL PROTECTED]:~/debian/cpuburn-1.4$ lintian ../cpuburn_1.4-1_i386.deb
E: cpuburn: statically-linked-binary ./usr/sbin/burnBX
I
Oohara Yuuma wrote:
dpkg compresses the diff file differently every time
I build .deb . The uncompressed .diff is same.
Is this an expected behavior?
gzip puts a timestamp in all .gz files it produces. Notice that file
displays it. Thus the file won't have the same checksum each time it's
Oohara Yuuma wrote:
dpkg compresses the diff file differently every time
I build .deb . The uncompressed .diff is same.
Is this an expected behavior?
gzip puts a timestamp in all .gz files it produces. Notice that file
displays it. Thus the file won't have the same checksum each time it's
Shaul Karl wrote:
According to the dh_movefiles man page,
dh_install is a much better program that can do everything this
one can, and more'.
Yet with dh_install I was only able to cp -a files without the addition
of rm them out of their current place.
What am I missing?
Shaul Karl wrote:
According to the dh_movefiles man page,
dh_install is a much better program that can do everything this
one can, and more'.
Yet with dh_install I was only able to cp -a files without the addition
of rm them out of their current place.
What am I missing?
. Compressing
those broke browsing.
Since I'm the first to do this deliberately, according to Joey Hess,
I'll simply continue using || true.
I wonder if you'd not be better off using something like
dh_compress -X htmltree , to make it just not act on anything in
whatever directory your html
Steve M. Robbins wrote:
Surely this is not the first time someone has run into this. Am I
doing something silly? It seems a bit odd to make the no package to
build diagnostic a fatal error.
It's almost always a mistake. I think you're the first person to do this
on purpose.
--
see shy jo
Sam Clegg wrote:
Aren't dev packages supposed to contain the SONAME:
libfoo0-dev (rather than libfoo-dev)
And then:
Conflicts: libfoo-dev
Provides: libfoo-dev
At least this is what the libpkg-guide says.
Why is this bug report filed on debhelper, which merely uses whatever
package
Bastian Kleineidam wrote:
On Fri, Apr 26, 2002 at 07:08:26PM -0700, David Caldwell wrote:
Instead of building in the source dir, create 2 build directories, cd to
each and ../configure with different options. Then in the make section, cd
into each build dir and make. So essentially you
Bastian Kleineidam wrote:
On Fri, Apr 26, 2002 at 07:08:26PM -0700, David Caldwell wrote:
Instead of building in the source dir, create 2 build directories, cd to
each and ../configure with different options. Then in the make section, cd
into each build dir and make. So essentially you
Matt Zimmerman wrote:
On Fri, Apr 19, 2002 at 02:33:37PM -0500, Colin Watson wrote:
On Fri, Apr 19, 2002 at 02:37:37PM +0200, Florent Rougon wrote:
dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
which I think should be OK since it is in the debhelper(1)
Matt Zimmerman wrote:
On Fri, Apr 19, 2002 at 02:33:37PM -0500, Colin Watson wrote:
On Fri, Apr 19, 2002 at 02:37:37PM +0200, Florent Rougon wrote:
dpkg-gencontrol: warning: unknown substitution variable
${misc:Depends}
which I think should be OK since it is in the
Roger Leigh wrote:
install man pages that are 0 length files. If you send me your build
tree I can try to debug it.
Ah, thanks. Some of the manpages are (oddly) zero-length. I'll have
to write some when I get time, if there are not any elsewhere.
All right, the next version of
Roger Leigh wrote:
install man pages that are 0 length files. If you send me your build
tree I can try to debug it.
Ah, thanks. Some of the manpages are (oddly) zero-length. I'll have
to write some when I get time, if there are not any elsewhere.
All right, the next version of debhelper
Roger Leigh wrote:
I'm getting some errors from dh_installman, and the manpages are not
getting installed:
$ dpkg-buildpackage -rfakeroot -us -uc
[...]
dh_installman -i
Use of uninitialized value in pattern match (m//) at /usr/bin/dh_installman line 181.
Use of uninitialized value in
Roger Leigh wrote:
I'm getting some errors from dh_installman, and the manpages are not
getting installed:
$ dpkg-buildpackage -rfakeroot -us -uc
[...]
dh_installman -i
Use of uninitialized value in pattern match (m//) at /usr/bin/dh_installman
line 181.
Use of uninitialized value in
Bob Hilliard wrote:
With Type: note, will the installation pause for user input
(Press [Enter]), or, if I want to be sure the user sees it, should I
make it a different type and ask for user input?
It'll pause.
--
see shy jo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Bob Hilliard wrote:
With Type: note, will the installation pause for user input
(Press [Enter]), or, if I want to be sure the user sees it, should I
make it a different type and ask for user input?
It'll pause.
--
see shy jo
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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
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. The
101 - 200 of 419 matches
Mail list logo
