Olе Streicher wrote:
Therefore, the package contains a couple of files which are quite old --
some help files, sources, documentation etc. date 1983 and 1984. This
leads to the Lintian *error* shown in the subject. Although I think it
is reasonable to overwrite this tag (the files actually
Paul Wise wrote:
Completely agreed, please file two bugs against debhelper about this.
Only after reading debhelper's bug logs where the decision was
researched and made to not --parallel by default, please.
--
see shy jo
signature.asc
Description: Digital signature
Scott Howard wrote:
From the debhelper manpage
Unless otherwise indicated, all debhelper documentation assumes that
you are using the most recent compatibility level, and in most cases
does not indicate if the behavior is different in an earlier
compatibility level, so if you are not using
Andrey Rahmatullin wrote:
How can I create this delta? The man page says only about creating a delta
for a tarball without a directory.
The delta is created for you when you run pristine-tar commit.
--
see shy jo
signature.asc
Description: Digital signature
Andrey Rahmatullin wrote:
On Wed, Jul 06, 2011 at 03:12:41PM +0200, Thomas Preud'homme wrote:
Does pristine-tar work if the upstream branch contains files which have
been
removed during repack?
Unfortunately the directory and the tarball must have identical contents.
That's not true,
George Zarkadas wrote:
-- In addition, the alternatives mechanism does not force any user to
make any changes to his/her scripts (as a choice to rename one of the
binaries would for the respective user group); they just set their
preference and use their scripts as before.
There are already
George Zarkadas wrote:
It builds these binary packages:
parallel - Execute jobs in parallel locally or using remote computers
I have not figured out what to do about moreutils containing a
/usr/bin/parallel that is not entirely command-line compatable with this
one. #597050
--
see shy jo
Matt Zagrabelny wrote:
Sure. That doesn't make it correct, optimal, or the best option, just
how things have always been done.
I understand the difference between remove and purge and the reason to
use both, but removing unmodified conf files seems like a win to me.
Keeps the clutter down.
Siegfried-Angel Gevatter Pujals (RainCT) wrote:
Hi Jean,
Something likes this should do:
--
Files: gtk/core_math2.cc
Copyright: 2004-2010, Thomas Okken
License: GPL-2
Files: gtk/core_math2.cc
Copyright: 1993, Sun Microsystems,
Helmut Grohne wrote:
I recently tried converting my packages to dh 7 and ... failed.
The simple rule
%:
dh $@
will fail miserably if there is any file named like a target. Try `touch
build' in your favourite dh-7-package to see it break.
GNU make users probably know that this is
Helmut Grohne wrote:
So will the new minimal example look like the following then?
#/usr/bin/make -Bf
%:
dh $@
Yes, that's how it's looking now.
--
see shy jo
signature.asc
Description: Digital signature
Russ Allbery wrote:
I really think this is a bug in make.
Probably, but who knows. It could just be a misfeature on which ghod
knows what somehow depends.
.PHONY: precompiled-binary-we-cannot-regenerate-with-gcc.o
We can change Policy if we have to. Arguably that line complies with
Policy,
Eduardo M KALINOWSKI wrote:
If the scripts are not directly executable, you can remove the
#!interpreter line from them. That should make the warning go away.
It would be better to talk with upstream so he does that.
If I were upstream and was pestered by a distribution to remove the
Eduardo M KALINOWSKI wrote:
If the policy suggestion that leads to that lintian warning is so
unreasonable, it might as well be taken off the policy.
I'm not aware of any such thing in policy.
--
see shy jo
signature.asc
Description: Digital signature
Franklin PIAT wrote:
I am looking for a sponsor for my package di-netboot-assistant.
(I am CCing debian-boot in case someone has some interest in it)
This looks like some nice work. I wonder if it would make sense for it
to be maintained inside the d-i project?
It's tightly related to d-i,
Christoph Biedl wrote:
The given config file sources $CONFIGFILE if present but asserts
FOO and BAR are defined there. Is this safe? I'd rather wipe out any
pre-existing values:
# Load config file, if it exists.
if [ -e $CONFIGFILE ]; then
+ FOO=
+ BAR=
.
Ben Finney wrote:
dh_install
cp: cannot stat `debian/tmp/cmavo.txt': No such file or directory
dh_install: command returned error code 256
make: *** [install] Error 1
dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit
status 2
bzr: ERROR: The build failed.
=
Ben Finney wrote:
Why, then, is it exiting with a No such file or directory error
trying to read the file from 'debian/tmp'?
Because of implementation details. It's easiest to check if the source
is in . , and if not stuff the path in debian/tmp into the list of
things to install, which later
Ben Finney wrote:
I recall recently seeing mention that 'dh_clean' could obey a
'debian/package_name.clean' file as a list of patterns or files to
clean.
However, I can't find it with search engines; package.clean returns
hits for package clean, and dh returns hits for all the dh_foo
Thibaut Paumard wrote:
Indeed, the problem is that per the instructions, I've modified my
update-yorickdoc utility to call dpkg-trigger when invoked from a
package's postinst. dpkg already triggers yorick-doc once after
unpacking the newly installed packages, which is sufficient. Later,
Neil Williams wrote:
Copyright issues:
1. The machine-interpretable copyright format is meant to be
hierarchical - Files: * should not appear before any other more specific
matches. i.e. exclude all the awkward files explicitly in turn, then the
last stanza is everything else.
That's not
Please see http://kitenet.net/~joey/code/filters/talkfilters-email :
| How did you manage to get valspeak, postmodern, pansy, and fudd, whose
| authors are unknown to be GPLed? According to the info page,
|
| While all of these filters have been available in one form or
| another in the
David Paleino wrote:
Is there any chance for filter to provide a libfilters library to interface
with? I've packaged talkfilters because it was a possible use of libtranslate
[2] [3], but that's not really necessary. I could try to patch it so that it
uses your filters package, but that would
Riku Voipio wrote:
I think the short term solution to this dilemma is to compile a list
of attributions needed to be included in advertizment material.
Also a list should be compiled attributions needed n documentation
(such as libjpeg's). Obviously most distributors/boob writers will
not
Bernhard R. Link wrote:
While a minimal chroot is good to test against missing
build-dependencies, a full real-world system is needed to test for
missing build-conflicts or configure switches to disable specific
autodetections.
But nothing in the current system ensures that packages are built
Bart Martens wrote:
On Wed, 2007-11-28 at 17:44 +0930, Paul Wise wrote:
I'd suggest that the copyright file
should be redone and done so it can be parsed automatically:
http://wiki.debian.org/Proposals/CopyrightFormat
Hi Paul,
As far as I know, it has not yet been decided that the
Neil Williams wrote:
I would consider its popularity low (187 popcon installs with 46
votes).
It's not that low. It looks like quite a few people find it useful, so
that's good.
Using absolute popcon numbers as indications of a package's popularity
isn't the best idea anyway, since we
K. Richard Pixley wrote:
Ok, sure. But that seems like a hack to me so that busybox can be
installed on regular desktop systems which presumably want coreutils, (and
friends), to be installed as the primary ls command. In this context,
busybox is more of a toy, or an evaluation
Neil Williams wrote:
Seems to me you have two choices: Use what you had without SecureApt.
Use the directory layout and tools that support SecureApt.
There is nothing in apt's security checking code that requires any
particular repository structure.
Example of apt repository that uses a flat
Andres Mejia wrote:
License: The game client and dedicated server are under GPL
The game data files are under a CCPL, specifically, the
Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
License http://creativecommons.org/licenses/by-nc-nd/3.0/.
Therefore the data
David Paleino wrote:
Why?
And a web server written in awk, then? Is that of any real-world use?
I've seen implementations of that on the Internet. I admit that this
is not enough reason to package it though.
d-i contains a web server written in shell, fwiw.
--
see shy jo
signature.asc
Thomas Goirand wrote:
Daniel many times told me that for example, I shouldn't use 2 blank
lines on my debian/rules, don't have empty space a end of line in my
copyright, and things like that.
I agree it doesn't mater MUCH, but it's still better the way he advise
me to correct.
I would much
Patrick Schönfeld wrote:
Hi people,
as i just finished a current version of mantis got it uploaded by Daniel
(thanks for that!) i have re-started working on smstools. Because the
upstream author and me detected that installation can lead into a
defunct state (because smsd is started, even
Daniel Baumann wrote:
* ${misc:Depends} is useless here
Please don't ask people to remove useless misc:Depends lines. At any
time a new version of a debhelper command could need to add a new
dependency to misc:Depends, and this only works if you keep it in your
depends line.
--
see shy jo
Interesting thread. I've never thought about generating the tarball this
way, though I do have a lot of native packages that probably shouldn't
be.
If one general-purpose tool to handle this rises to the top and is
usable by many people, it would be a good candidate for addition to
devscripts.
Jari Aalto wrote:
See http://ftp-master.debian.org/REJECT-FAQ.html down near the bottom
near debian/rules.
This is bad, such micromanagement for few commented lines should not
warrant rejection criteria by the ftp masters.
Except the FAQ doesn't say that it's a rejection criteria, just
Tyler MacDonald wrote:
I can't find a consistent rule for what should go into man1 vs. man8. For
instance, apt-get can be used as an unprivileged user to download source
tarballs, but it's in man8, whereas defoma-reconfigure, which can only be
run as root, is located in man1.
Tyler MacDonald wrote:
tarballs, but it's in man8, whereas defoma-reconfigure, which can only be
Ups, I read defoma-reconfigure as dpkg-reconfigure. :-)
--
see shy jo
signature.asc
Description: Digital signature
Rafael Laboissiere wrote:
Is it acceptable to manually close a bug which is fixed in experimental
but not yet in unstable, especially when there are no plans regarding the
upload of the fixed version to unstable in the foreseeable future?
Yes, just be sure to version your close message so that
Seems highly similar to snowdrop which is already packaged..
Jari Aalto wrote:
I'm looking for sponsor.
-- Jari
Status
NEW Package, not in Debian
Availability
http://sponsors.debian.net/viewpkg.php?id=218
Other information
Lintian clean (unstable)
Pbuilder
Bernhard R. Link wrote:
The general suggestion is to not include the debian/ directory in the
release tarball. The reason is that by the format of the Debian source
packages no files can be removed by another person's .diff.gz and some
tools like debhelper act on (non)existance of specific
Bas Wijnen wrote:
I think this is because of the signing of packages which happens and is
checked nowadays. If two versions are available, of which only one is
trusted, it chooses the trusted one, no matter what the versions are.
AFAIK apt does not use whether a repository is signed to make
Anders Lennartsson wrote:
This command line application encodes and decodes base64 and can be
used in redirects and pipes etc.
Can't you just use uuencode -m and uudecode?
--
see shy jo
signature.asc
Description: Digital signature
Lars Wirzenius wrote:
I'm going to dip my spoon into this soup, because I dislike soup, and
this one especially irks me.
Even ice cream soup?
Reviewing other people's patches in large quantities every day is
something that few people will be happy to do for more than a few
days. After that,
Mario Iseli wrote:
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}
(You don't need the second variable, it isn't defined anywhere...)
Automatic generation of miscellaneous dependencies.
Some debhelper commands may make the generated package need to
Manoj Srivastava wrote:
It would be nicer to have it completely described (and in an updated
manner) in a definitive reference, of course.
Sure. Should be in the documentation of debconf itself.
debconf-devel(7), anyone?
(policy also contains a formal definition of the debconf
Russ Allbery wrote:
I hate to say this, since actually implementing it is a lot of work in
supporting programs like debhelper, but if the debconf-2.0 pseudopackage
was introduced prior to a new feature in the debconf interface there needs
to be a debconf-2.1 or debconf-3.0 as well. If
Florian Weimer wrote:
I'm not sure what users would expect from such a service.
In the case of debsecan, as an admin I would expect something
consistent, so I can, for example, start the day with a coffee and a
security report, rather than getting the report at some random time
during the day.
Henrique de Moraes Holschuh wrote:
at has a very bad history security-wise, and I really doubt anyone is
seriously maintaining and fixing that thing. Now, if someone would rewrite
from scratch an at designed and implemented for security, that would be
very cool indeed.
at had one security
Rogério Brito wrote:
What exactly should I do? I would like to host this somewhere where
others could have access to a svn repository. I think that I can
register a new project on BerliOS, but suggestions are welcome.
alioth.debian.org is also an option for team maintenance.
--
see shy jo
Rogério Brito wrote:
I tried to send the message attached two times already, but it seems
that it hasn't reached the list.
Anyway, if anybody could help, I'd be grateful.
I've been following that bug and had been expecting some activity to
occur on the vrms mailing list since they redirected
Mark Seaborn wrote:
LD_PRELOAD isn't good enough. Plash needs to replace *all* uses of
system calls that use filenames, including glibc's internal uses of
those system calls. Back in the day of glibc 2.2.5, you *could* do
this by overriding __open and __libc_open as well as open. But
with
Steve Langasek wrote:
If you rerun autoconf/automake/libtool at package build-time, when you don't
need to, what you get are large diffs against upstream every time a new
version of the autotools becomes available. Aside from wasting (a little)
space in the archive, that makes it harder for
Steve Langasek wrote:
Hmm, I'm not really sure whether that fits with policy's intent regarding
the effects of the debian/clean target.
This must undo any effects that the `build' and `binary' targets
may have had, except that it should leave alone any output files
Manoj Srivastava wrote:
I appreciate the build system for certain red hat and suse packages not
being arcane and distribution specific when I try and incorporate
changes made in packages on those distributions, and I tend to return
the favour.
Grep through the rpm book for all the %
Manoj Srivastava wrote:
I prefer to have these command (usually, mv, cp, gzip, etc)
explicitly present, so one does not have to go looking through the
library to guess what is being done.
Wow, here it is 2005, a whole 8 years since debhelper was introduced and
Manoj still doesn't
Antti-Juhani Kaijanaho wrote:
If I were to receive a bug report, say wishlist severity, containing a
patch that rewrites one of my packages' debian/rules to use debhelper, I
would be very upset: it would feel like an insult toward my style of
packaging.
You need to grow a thicker skin. By
Antti-Juhani Kaijanaho wrote:
Don't do it without the maintainer's go-ahead. The current best
practice is to use whatever (non-evil thing that) works for the
maintainer.
This best practice fails miserably if the maintainer is not always
perfectly responsive. As soon as the maintainer goes on
Ben Finney wrote:
That would be a downside (and kills it for the primary use I had in
mind, '#!/usr/bin/env perl -w').
Of course #!/usr/bin/env perl\nuse warnings; is equivilant.
--
see shy jo
signature.asc
Description: Digital signature
Jereme Corrado wrote:
I just added a NEWS.Debian file to one of my packages and the
Developers Reference, (sec. 6.3.4) suggests that one should check the
formatting with dpkg-parsechangelogs.
I read the man page for dpkg-parsechangelogs and played around a
little but it's unclear to me how
Brian Sutherland wrote:
I have quite a difficult config file problem to debconfify, and would
like to ask advice.
The config file can contain a number of lang $locale settings, of which
the first is the requested translation and the rest are backups.
How best to keep the ordering.
Brian Sutherland wrote:
I have quite a difficult config file problem to debconfify, and would
like to ask advice.
The config file can contain a number of lang $locale settings, of which
the first is the requested translation and the rest are backups.
How best to keep the ordering.
Rene Engelhard wrote:
any debian rules.
the foo-0.1 is a convention. if your stuff doesn't follow it it is broken.
No, there is no convention and it doesn't matter at all what you name
the package's source directory. This has been completly unnecessary for
years.
And: You *could* use a
Rene Engelhard wrote:
any debian rules.
the foo-0.1 is a convention. if your stuff doesn't follow it it is broken.
No, there is no convention and it doesn't matter at all what you name
the package's source directory. This has been completly unnecessary for
years.
And: You *could* use a
martin f krafft wrote:
I know that debconf-devel(7) lists the debconf protocol and that the
shell and Perl wrappers are basically 1:1. Still, I wonder if there
is any documentation about these (which may be a little more
accessible to new users). Could someone please take a clue stick and
martin f krafft wrote:
I know that debconf-devel(7) lists the debconf protocol and that the
shell and Perl wrappers are basically 1:1. Still, I wonder if there
is any documentation about these (which may be a little more
accessible to new users). Could someone please take a clue stick and
Adrian 'Dagurashibanipal' von Bidder wrote:
Thanks for the url. I'm not sure how that solves my problem. As I
understand you, I need to convince the upstream maintainer to switch
to LSB style initscript. I can try doing that. The initscript has
Yes, that was my idea - so everybody can use
Adrian 'Dagurashibanipal' von Bidder wrote:
Thanks for the url. I'm not sure how that solves my problem. As I
understand you, I need to convince the upstream maintainer to switch
to LSB style initscript. I can try doing that. The initscript has
Yes, that was my idea - so everybody can use
Adrian 'Dagurashibanipal' von Bidder wrote:
On Thursday 15 July 2004 15.15, Martin Dickopp wrote:
Sebastian Henschel [EMAIL PROTECTED] writes:
[/etc/default]
See Policy 9.3.2. (Disclaimer: IANADD.)
Which does only say:
| To ensure that vital configurable values are always available, the
Adrian 'Dagurashibanipal' von Bidder wrote:
On Thursday 15 July 2004 15.15, Martin Dickopp wrote:
Sebastian Henschel [EMAIL PROTECTED] writes:
[/etc/default]
See Policy 9.3.2. (Disclaimer: IANADD.)
Which does only say:
| To ensure that vital configurable values are always available, the
Matthew Palmer wrote:
I was under the impression that dh_installman renamed the file appropriately
according to the .TH line -- at least, that's what the manpage suggests.
It uses the .TH line to get the section, but AFAIK there is nothing
similar in the content of the man page to work out the
Matthew Palmer wrote:
I was under the impression that dh_installman renamed the file appropriately
according to the .TH line -- at least, that's what the manpage suggests.
It uses the .TH line to get the section, but AFAIK there is nothing
similar in the content of the man page to work out the
Eike zyro Sauer wrote:
Raphael Goulais schrieb:
- Why do you remove /var/log/cvs-autoreleasedeb.log at postrm, since
the log files are in /var/log/cvs-autoreleasedeb/ ? Also, I don't
think you should remove the log files anyway, even on a purge.
Is this consensus?
I thought I'd
Eike zyro Sauer wrote:
Raphael Goulais schrieb:
- Why do you remove /var/log/cvs-autoreleasedeb.log at postrm, since
the log files are in /var/log/cvs-autoreleasedeb/ ? Also, I don't
think you should remove the log files anyway, even on a purge.
Is this consensus?
I thought I'd
Matthew Palmer wrote:
package I sponsor. I want to know if they are not able to send me a
package that will build properly. I want to work with them and be
Since you only get packages for sponsorship which have built in a clean sid
chroot out of my system, you can be fairly sure of that.
Matthew Palmer wrote:
package I sponsor. I want to know if they are not able to send me a
package that will build properly. I want to work with them and be
Since you only get packages for sponsorship which have built in a clean sid
chroot out of my system, you can be fairly sure of that.
Matthew Palmer wrote:
So, comments, brickbats, acclaim, whatever. Throw it at me.
Well I don't think that this system as described would be of any use to
me. I want to maintain a close relationship with the people whose
package I sponsor. I want to know if they are not able to send me a
package
Matthew Palmer wrote:
So, comments, brickbats, acclaim, whatever. Throw it at me.
Well I don't think that this system as described would be of any use to
me. I want to maintain a close relationship with the people whose
package I sponsor. I want to know if they are not able to send me a
package
Stephen Gran wrote:
dh_installinit -p foo -n
dh_installinit -a
dh_installinit -p foo -n
dh_installinit -a -N foo
--
see shy jo
signature.asc
Description: Digital signature
Stephen Gran wrote:
dh_installinit -p foo -n
dh_installinit -a
dh_installinit -p foo -n
dh_installinit -a -N foo
--
see shy jo
signature.asc
Description: Digital signature
Stephen Gran wrote:
I am working on a package that uses po files, inherited from the
previous maintainer, and I am getting this during build:
po2debconf debian/clamav-daemon.templates debian/clamav-daemon/DEBIAN/templates
Warning:Outdated PO file: debian/po/fr.po, running
Stephen Gran wrote:
I am working on a package that uses po files, inherited from the
previous maintainer, and I am getting this during build:
po2debconf debian/clamav-daemon.templates
debian/clamav-daemon/DEBIAN/templates
Warning:Outdated PO file: debian/po/fr.po, running
Roberto Cioffi wrote:
I've just uploaded a new package: wmbatterie.
It's a dockapp for windowmaker that shows acpi information read from
proc filesystem.
It can be reached at:
http://mentors.debian.net/debian/dists/unstable/
or at:
http://utenti.lycos.it/bigjacob/debian/
I'm
Roberto Cioffi wrote:
Joey Hess wrote:
As the author of wmbattery, and a debian developer, I wish you
could find a new name for your program. I think that having two
programs that do the own thing have names differing only by
pluralisation will be very confusing to users.
I'm
Roberto Cioffi wrote:
I've just uploaded a new package: wmbatterie.
It's a dockapp for windowmaker that shows acpi information read from
proc filesystem.
It can be reached at:
http://mentors.debian.net/debian/dists/unstable/
or at:
http://utenti.lycos.it/bigjacob/debian/
I'm
Roberto Cioffi wrote:
Joey Hess wrote:
As the author of wmbattery, and a debian developer, I wish you
could find a new name for your program. I think that having two
programs that do the own thing have names differing only by
pluralisation will be very confusing to users.
I'm
Frank Küster wrote:
after changing the configuration scheme considerably, I have a couple of
unused debconf templates left. I guess it's a good idea to unregister
them from the database to keep it as small as possible.
Where should I do this? Not before the new package is unpacked, but also
Frank Küster wrote:
after changing the configuration scheme considerably, I have a couple of
unused debconf templates left. I guess it's a good idea to unregister
them from the database to keep it as small as possible.
Where should I do this? Not before the new package is unpacked, but also
Zenaan Harkness wrote:
debhelper puts the following into the clean rule in debian/rules:
No it didn't.
Should I email this to the debhelper script maintainer?
Only if you want me to bounce it to the maintainer of the package that
actually put those lines there.
--
see shy jo
Eric Wong wrote:
Hello, I wrote a new source-building tool for APT and am looking for
somebody to sponsor it.
Here's an excerpt I wrote for the README file:
Why APT-Fu? Why not use an existing source-building tool in Debian?
I think it's a bad idea to add yet another duplicate tool
Eric Wong wrote:
Hello, I wrote a new source-building tool for APT and am looking for
somebody to sponsor it.
Here's an excerpt I wrote for the README file:
Why APT-Fu? Why not use an existing source-building tool in Debian?
I think it's a bad idea to add yet another duplicate tool
Frank Küster wrote:
It isn't, or rather Joey has misunderstood me - he probably knows every
piece of code by heart.
Hardly, and obviously not. I'd forgotten about the seen flag cache used
in making it easier to do scripts that back up. Besides, it's 30kloc.. ;-)
Seen (after seeing in fact):
Frank Küster wrote:
It wasn't me ;-) One of the maintainers of tetex brought up a
modification to fix a bug which altered the seen flag, and I wanted to
suggest a somewhat different approach. I agree, however, with Atsuhito
that the question has to be shown again to anybody who has answered it
Frank Küster wrote:
It isn't, or rather Joey has misunderstood me - he probably knows every
piece of code by heart.
Hardly, and obviously not. I'd forgotten about the seen flag cache used
in making it easier to do scripts that back up. Besides, it's 30kloc.. ;-)
Seen (after seeing in fact):
Frank Küster wrote:
It wasn't me ;-) One of the maintainers of tetex brought up a
modification to fix a bug which altered the seen flag, and I wanted to
suggest a somewhat different approach. I agree, however, with Atsuhito
that the question has to be shown again to anybody who has answered it
Frank Küster wrote:
[EMAIL PROTECTED]:~$ debconf-show tetex
Configuration database frankdb was not initialized.
Probably it would be better if you point me to some documentation so
that I don't have to bother the list. There no occurence of init in
debconf(7), debconf-devel(7) or
Frank Küster wrote:
+ db_fset tetex-bin/hyphen seen false
+ db_input medium tetex-bin/hyphen || true
+#db_fset tetex-bin/hyphen seen true
Please reconsider playing with the seen flag, unless you know *exactly*
what you're doing. Since you see the question
Frank Küster wrote:
[EMAIL PROTECTED]:~$ debconf-show tetex
Configuration database frankdb was not initialized.
Probably it would be better if you point me to some documentation so
that I don't have to bother the list. There no occurence of init in
debconf(7), debconf-devel(7) or
Frank Küster wrote:
+ db_fset tetex-bin/hyphen seen false
+ db_input medium tetex-bin/hyphen || true
+#db_fset tetex-bin/hyphen seen true
Please reconsider playing with the seen flag, unless you know *exactly*
what you're doing. Since you see the question
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
1 - 100 of 419 matches
Mail list logo
