Hi,
Long before I heard about reprepro, I also wrote my own Python script to
manage my local and remote Debian repositories (and I'm still using it):
http://people.debian.org/~frn/fmdr
documented at:
http://people.debian.org/~frn/fmdr.txt
To follow the pattern on
Hi,
Siegfried-Angel [EMAIL PROTECTED] wrote:
The package appears to be lintian clean, except for this messages
(checking the .deb):
- E: qttube: postinst-does-not-call-updatemenus usr/share/menu/qttube
- E: qttube: postrm-does-not-call-updatemenus usr/share/menu/qttube
However,
Siegfried-Angel [EMAIL PROTECTED] wrote:
Sorry, the files had wrong versioning (-0ubuntu1) and I corrected
that. You can dget it from here now:
http://mentors.debian.net/debian/pool/main/q/qttube/qttube_0.2~pre1-1.dsc
OK.
2007/8/8, Florent Rougon [EMAIL PROTECTED]:
Maybe your qttube.post
Warren Turkal [EMAIL PROTECTED] wrote:
Why does this matter? I don't see every other package specifically
mentioning who made it or what OS it was originally developed for.
Of course it matters. I don't know whether there is an official (i.e.,
from Apple) public full specification for HFS+,
Joachim Reichel [EMAIL PROTECTED] wrote:
Now here's the part that I forgot: debian/rules usually has a binary-arch and
binary-indep target. Run debian/rules clean binary-arch and now you can
check whether the package will also run fine on a Debian autobuilder.
The problem is that sbuild
Hi,
Romain Beauxis [EMAIL PROTECTED] wrote:
Well, if it's only meant for using the application in your current X server,
you simply have to bind mount the /tmp directory in the chroot:
mount -t none -o bind /tmp /path/to/chroot/tmp
I think it's enough to get the chroot to use the X server
[Running X apps in a chroot]
Székelyi Szabolcs [EMAIL PROTECTED] wrote:
You can. Just run an sshd inside the chroot and enable X forwarding on
the ssh server sitting inside and the ssh client connecting from outside
(from an xterm, of course).
There is another way, which I've been using for
Charles Plessy [EMAIL PROTECTED] wrote:
As one of the program I package was recently automakified, I had to
change debian/rules to deal with this. While comparing with other
packages, I realised that often $(MAKE) is used instead of make in
debian/rules. In case of trivial packages which do
Charles Plessy [EMAIL PROTECTED] wrote:
#!/bin/sh
echo -e AMAP is now available under /usr/bin/amap.\nThis wrapper
(/usr/bin/amap-align) will be removed in the future.
exec /usr/bin/amap $@
'echo -e' is not specified by POSIX. If you want to use escapes such as
\n, you'd better use printf
Hi,
Daniel Leidert [EMAIL PROTECTED] wrote:
Definitely README.Debian; probably a good idea in copyright, where you
mention the download location.
The Developers Reference gives several useful hints for this situation
and suggests[1] to use a more specific file: README.Debian-source.
[1]
Russ Allbery [EMAIL PROTECTED] wrote:
I still think that debian/copyright is a more natural location for this
information. debian/copyright is where we're required to specify the
source of the upstream tarball. Any customizations to the upstream
tarball seem to me to be part and parcel with
olaf [EMAIL PROTECTED] wrote:
I havnt uploaded anything yet and I doubt that I am able to upload the files
with suse-linux at my school (no dput?). What shall I do? :(
Presumably, putting all the following files:
/usr/bin/dput
/usr/bin/dcut [not sure if this one is actually needed]
Damyan Ivanov [EMAIL PROTECTED] wrote:
3.7.2.2Oct 2006
* Maintainer scripts must not be world writeable (up from a
should to a must) [6.1]
IMHO, this is something that makes 3.7.2.0 and 3.7.2.2 two non-equal
Marc Haber [EMAIL PROTECTED] wrote:
These are 23 lines of code which have the potential for a lot of bugs.
I do not think it is a good idea to cutpaste this code into a hundred
packages.
I didn't know you were alone maintaining a hundred of packages that need
this particular removal code.
Marc Haber [EMAIL PROTECTED] wrote:
I didn't know you were alone maintaining a hundred of packages that need
this particular removal code. Interesting.
You seem to be deliberately misunderstanding me. I'll stop wasting my
time.
I meant that when a maintainer copies code in its maintainer
Russ Allbery [EMAIL PROTECTED] wrote:
In other words, use previous-version+svn-stuff if you're packaging
that version plus some additional upstream modifications, and use
next-version+svn-stuff if you're packaging an alpha or beta arelease
^
I hope you meant '~' here.
of
Marc Haber [EMAIL PROTECTED] wrote:
I doubt this.
The code is definitely not what I call complex. The tetex-bin package
is, but not that particular piece of code, once isolated.
Additionally, this is a huge waste of maintainer time. Code like this
_BELONGS_ into a standardized tool.
Andrew Donnellan [EMAIL PROTECTED] wrote:
So for a snapshot of revision 91 between stable version 2.0 and future
version 2.1, would something like:
2.1~20070123svn.r91
be OK?
Ah, so now that we have this '~' allowed by dpkg, we have to use it
everywhere?
You cannot predict the future.
Manoj Srivastava [EMAIL PROTECTED] wrote:
Ah, so now that we have this '~' allowed by dpkg, we have to use it
everywhere?
No, but we should use it in situations for which is was
specifically designed for, no?
Precisely. And it was *not* designed for CVS/SVN/whatever RCS snapshots.
Margarita Manterola [EMAIL PROTECTED] wrote:
The subject still says configuration file and not conffile.
There's a difference between them, and you should know it.
The subject here says configuration file because I fixed it. It seems
you are the one who doesn't know the difference between a
Marc Haber [EMAIL PROTECTED] wrote:
The file is under ucf control (I omitted that to lessen complexity),
Hey! We are doctors. You have to tell us _everything_. :-)
but ucf does not know about the file any more if it is not in the new
package and will therefore not handle it.
Uh, if you
Hi,
Marc Haber [EMAIL PROTECTED] wrote:
I have a package with a bunch of configuration files that are managed
by my maintainer scripts and not by dpkg.
Therefore, these configuration files are *not* conffiles. Your Subject
line was misleading (especially considering we are on -mentors).
(1)
Santiago Vila [EMAIL PROTECTED] wrote:
Instead of 1,2,3 you could do 1,2,3 only when upgrading from a version
previous than the one not having a.conf anymore
Sure.
and in case that (3) happens, keep a.conf untouched, instead of
renaming it (assuming the program will not read a.conf
Daniel Baumann [EMAIL PROTECTED] wrote:
* $(MAKE) install DESTDIR=`pwd`/debian/fspanel
- do *not* use `pwd`, but $(CURDIR).
And when using $(CURDIR), please enclose the path in double quotes (),
because $(CURDIR) may well contain spaces. There are so many packages
that get this wrong...
Hi,
I'm not expert in these matters, but since nobody answered, I'll give it
a try.
Hynek Hanke [EMAIL PROTECTED] wrote:
I have no direct controll over /dev/softsynth and /proc/speakup as
they are not created by my package.
Sounds like the crucial point to me. As for /proc/speakup, I think
Paul Cager [EMAIL PROTECTED] wrote:
The policy *does* distinguish between lines starting with one space
(paragraphs with word-wrapping) and lines starting with two or more spaces
(non-wrapped if panning is possible, otherwise hard-wrapped), so I think
there is a strong policy basis for the
Daniel Baumann [EMAIL PROTECTED] wrote:
* a build-depends on gawk | awk doesn't make sense. either you use
specifically features of gawk, and then you only depend on gawk, or
your depends is fulfilled by any awk implementations, which means,
you don't need to list it
Err, no.
Asheesh Laroia [EMAIL PROTECTED] wrote:
I'm not a Debian developer, but I would think the easiest thing to do is to
install pbuilder and create a chroot for Debian. Since the source package
will be the same (libgmp-dev, I'd guess) for both, you can use pbuilder to
generate the Debian package
Goswin von Brederlow [EMAIL PROTECTED] wrote:
The underlying problem is that build-arch/indep are not mandatory and
thus building must call the build target.
This makes sense, thanks for pointing it out.
If build-indep does take a considerable time then you can use the
following hack:
While we're at it, you should also consider adding the appropriate
texlive packages to your B-D as an alternative to the tetex packages.
Sooner or later (may well happen for lenny), the tetex packages will be
removed, so you'll have to do that anyway.
--
Florent
--
To UNSUBSCRIBE, email to
Hi,
Joachim Reichel [EMAIL PROTECTED] wrote:
Hi,
section 7.6 of the policy states that Build-Depends-Indep must be
satisfied if the build target is invoked.
[...]
Now, if my sponsor uploads this package, it will still fail, right? If
Build-Depends-Indep is not satisfied by accident, the
Warren Turkal [EMAIL PROTECTED] wrote:
Okay, the build deps now look like:
Build-Depends: cdbs, debhelper (= 5), autotools-dev, gfortran, tex, texi2dvi
Ugh, what's this 'tex' package?
Before blindly doing what others tell you, you'd better think a little
bit (I'm sure Patrick didn't want to
Hi,
Ben Hutchings [EMAIL PROTECTED] wrote:
The requirement for #! / was documented in 4.1BSD but the
implementation never really required it - compare
http://www.in-ulm.de/~mascheck/various/shebang/exec.2.html and
http://www.in-ulm.de/~mascheck/various/shebang/sys1.c.html
(Found via
Daniel Baumann [EMAIL PROTECTED] wrote:
* this is ugly:
---snip---
#! /bin/sh /usr/share/dpatch/dpatch-run
---snapp---
and this is beautiful:
---snipp---
#!/bin/sh /usr/share/dpatch/dpatch-run
---snapp---
How so?
There are two reasons why I always use the first style:
- it
Mike Hommey [EMAIL PROTECTED] wrote:
If you mean rotation of pictures depending on the orientation tag in
the exif data, jhead already does that, lossless, with jpegtran (which
is in libjpeg-progs)
Since we are talking about this, I'd like to mention exifautotran(1),
which also does that, and
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Reduces the memory wasted and speeds up processing in dpkg, dselect,
apt, aptitude, britney, ...
It's also useful for simple humans looking at the dependencies of a
package: having all dependencies, including those on essential packages,
would
Székelyi Szabolcs [EMAIL PROTECTED] wrote:
That's right. But why is Replaces needed in the case of an MTA? If a
package Providing mail-transport-agent is installed, and the user is
about to explicitly install another package which also Provides and
Conflicts with mail-transport-agent, then
Hi,
Székelyi Szabolcs [EMAIL PROTECTED] wrote:
The soversion is usually added to the -dev package name to be able to
support multiple versions of a library off-line, which means all
versions can be found in the archive, but only one can be installed on
the user's machine. The question is,
Kapil Hari Paranjape [EMAIL PROTECTED] wrote:
As far as I understand it the DFSG does not apply to Copyright license
documents. For example the GNU COPYING document contains exactly
the same sentence.
That's right.
The file copying.dj is DJ Delorie's copyright license document so it
*can*
Hi,
Charles Plessy [EMAIL PROTECTED] wrote:
1) How can I know if they are redistributable at all, for instance if
they contain non-free fonts? In the worst case, do I have to repackage
the sources as well?
I'll leave that to the real experts on the matter.
2) There are simple text versions
gregor herrmann [EMAIL PROTECTED] wrote:
TTBOMK MS Office files don't contain any fonts (that's why they often look
suboptimal if used on a machine where the referenced fonts are
missing).
I believe there is[1] an option in MSWord to embed the fonts in a
document. But since it's an option,
Kurt B. Kaiser [EMAIL PROTECTED] wrote:
The QA upload switched from Build-Depends-Indep to Build-Depends and
I left that alone. Maybe both of these (identical) should exist?
Build-Depends: debhelper is necessary because dh_clean is in the clean
target, and Build-Depends-Indep might be needed
[EMAIL PROTECTED] (Francesco Namuri) wrote:
I think this is the problem... It's a packaging problem?
Doesn't look so. Maybe ask the buildd admins...
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bas Wijnen [EMAIL PROTECTED] wrote:
Also, someone noted that this script is vulnerable to a symlink attack in
/tmp. I haven't found a good solution for that though, because I want to have
a reachable build tree under a normal name, where I can see what all the
files look like.
If you
Andrew Donnellan [EMAIL PROTECTED] wrote:
What does this do that python-xmms/pyxmms does not do?
Maybe this might just be a *standalone application* rather than a library?
The standalone application corresponding to (and relying on) PyXMMS is
PyXMMS-remote (found in the pyxmms-remote Debian
Hi,
Rogério Brito [EMAIL PROTECTED] wrote:
I just read the copyright file and I thought that it would be
distributable. Are there any conflicts in what is written there?
I pointed out the problems I saw in the initial thread about this RFS.
Please check the debian-mentors archives.
Please
Rogério Brito [EMAIL PROTECTED] wrote:
I have been using your package for some time right now and it seems to
work fine.
I would love to see your package uploaded to Debian and I have seen that
the latest version you published is both lintian and linda clean.
This is all very nice, but last
Often, changelog entries explain why certain technical packaging
decisions were made (for instance, Build-Depend on foo = $version
because of $reason). These entries are definitely useful, even if they
happened before the first release uploaded to the Debian archive.
--
Florent
--
To
LI Daobing [EMAIL PROTECTED] wrote:
These two files were not added by me. they are in the original
source[1]. so I think I have to repackage the source if I want to clear
the warnings.
[1]
$ tar tzvf qterm_0.4.0pre4.orig.tar.gz | grep ex$
-rw-r--r-- nichloas/nichloas1877 2003-04-29
Olly Betts [EMAIL PROTECTED] wrote:
The autoconf manual, section 10.10 Limitations of Shell Builtins (in
the CVS HEAD version at least) says:
`!'
The Unix version 7 shell did not support negating the exit status
of commands with `!', and this feature is still absent from more
Justin Pryzby [EMAIL PROTECTED] wrote:
It's my understanding that test ! is more portable than ! test (same
for [ !).
I would be very surprised to know why.
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Grrmpfff...
Florent Rougon [EMAIL PROTECTED] wrote:
I would be very surprised to know why.
^
interested (of course)
And yes, surprised if that was true.
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe
Kevin Bube [EMAIL PROTECTED] wrote:
Hi all,
I uploaded a new package version to mentors.debian.net. The changelog
file lists all changes done. I think I addressed all problems which
still remained.
http://mentors.debian.net/debian/pool/non-free/u/ is currently empty.
Huh?
A slight catch:
Bas Wijnen [EMAIL PROTECTED] wrote:
Not at all, I am entirely looking at it from a user's perspective, in
particular a user which doesn't want non-free software (those people are the
reason contrib and non-free exist, so it seems appropriate to look especially
at them).
No, there is a much
Charles Plessy [EMAIL PROTECTED] wrote:
I have made /usr/share/doc/probcons-extra a symlink to
/usr/share/doc/probcons (probcons-extra depends on probcons). Is it OK
to do such things? ^^
this is important
Yes, this is
Vedran Furaè [EMAIL PROTECTED] wrote:
Thanks for uploading. I see that parser at NEW didn't catch the Closes:
line. I will close that bug once it's accepted.
If you used the right syntax, that probably happened because it wasn't
part of the last changelog entry, in which case
Redefined Horizons [EMAIL PROTECTED] wrote:
Here is my question. Can I create a custom Debian package for Library A that
satisfies the dependency requirements of Package A, but still keep the older
version of Library A required by my other programs?
Of course. Look for example at the GTK+
Charles Plessy [EMAIL PROTECTED] wrote:
Le Fri, Jun 02, 2006 at 04:10:29PM +0200, Florent Rougon a écrit :
The files pertaining to the Debian packaging are
(c) 2006 Kevin Bube.
Maybe one could suggest a replacement
Hi,
Kevin Bube [EMAIL PROTECTED] wrote:
After reading bug #366234 I set debhelper requirement to =5.0.35. See
Fine. That's also what I had done with lmodern in the meantime.
3. I'm not a native english speaker, but I would modify the Description
field this way:
[snip]
Okay, I
Nicolas Duboc [EMAIL PROTECTED] wrote:
About the second issue, the current state of my work includes the
modules in the diff.gz file. This file is then 531K. Do you think it is
acceptable ?
Maybe you'd be better off with something like quilt, dpatch or cdbs,
that would allow clean separation
Hi,
Kevin Bube [EMAIL PROTECTED] wrote:
The defoma-hints and scale files are indeed quite tricky. I modified the
scales file by hand as the font itself declares all shapes as medium, so
fontscale duplictes all fonts. I will reread the docs and rework the
defoma-hints.
OK. BTW, since the
Hi,
Ralf Stubner [EMAIL PROTECTED] wrote:
I have valid E-Mail addresses that do not contain my surname. ;-)
Sure, but the license says you have to indicate your name *and* email
address. You can't hide. :)
However, it was indeed an oversight to not mark the changed file
properly as required
Jean Parpaillon [EMAIL PROTECTED] wrote:
- Manpage is in upstream. But manpage is in nroff format as I don't know
autotools enough to handle manpage transformation with it...
What do you mean by manpage transformation? Transformation to .dvi? It's
not unusual to have manpages in *roff
Jean Parpaillon [EMAIL PROTECTED] wrote:
It's because someone suggested me to have the manpage in xml format so
that I could get it in pdf or dvi or I don't know...
Well, XML isn't necessary for that. You can get DVI from *roff with
'man -Tdvi' and PDF with dvipdfm(x)...
...Of course *roff
Hi,
Kevin Bube [EMAIL PROTECTED] wrote:
Hi mentors,
I am looking for a sponsor for the urw-garamond package (ITP #367223).
It builds cleanly with debuild and installs and works with
unstable. This is my first attempt for a Debian package so comments are
very welcome.
Your package is
Pádraig Brady [EMAIL PROTECTED] wrote:
Done. The following source package was built with:
dpkg-source -b fslint-2.15 fslint_2.15.orig.tar.gz
[...]
I'm confused as to why it didn't ask me to sign it.
I don't know if that's expected (I usually use 'debuild' to build my
source packages), but
Kevin Bube [EMAIL PROTECTED] wrote:
Yes, the package is done for unstable. Is X.org 7 expected to go into
etch? Or is it better to use the X11R6 locations for now?
No, packaging for X.org was the right decision.
I'll try to have a look at your package one of these days, but probably
not this
Hi,
Yaroslav Halchenko [EMAIL PROTECTED] wrote:
.pdf.gz versions. And at least I would expect all -doc packages to have
uncompressed .pdfs since neither of the pdf viewers to me experience
handle transparent decompression of pdf.gz
I know it doesn't really answer your question, but a simple
Franz Pletz [EMAIL PROTECTED] wrote:
W: lopster; A binary links against a library it does not use symbols from
This package contains a binary that links against a library that is
not in the Depends line. This may also be a bug in the library which
does not have a shlibs file.
I've
Bart Martens [EMAIL PROTECTED] wrote:
Anyway, I don't see a problem with the readability of debian/rules with
the commented dh_ lines, and I agree with Jari Aalto that leaving the
commented dh_ lines can be useful, so I would vote allow if a
discussion would be held for this.
I disagree. If
Panu Kalliokoski [EMAIL PROTECTED] wrote:
Well, I must add that I don't find the recommendation very smart either,
but probably there's somebody out there that has terrible difficulties
in not reading commented-out lines or something like that. I personally
The threshold where commented
Jari Aalto [EMAIL PROTECTED] wrote:
I disagree with comments about removing the lines from from
debian/rules (debhelper calls that are unused). This file is used by
the maintainer of the package and he knows best what is the most
effective way to organize his works.
IME, it is not very
Romain Beauxis [EMAIL PROTECTED] wrote:
Would you argue that you are not skilled if you comment your dh_* calls?
No, rather that if you're skilled, you don't need to comment them.
You could simply not want to loose time to find back the good order...
I'd say that if you're ready to sacrifice
Simon Richter [EMAIL PROTECTED] wrote:
Exactly. So in order to understand my own packages better I leave the
dh_* calls in, commented out so I can grep for them and see that they
are disabled.
Well, I never felt this need.
Being a DD, I think I should be able to make that judgement for
Justin Pryzby [EMAIL PROTECTED] wrote:
Agreed; my motivation for leaving commented lines around is that it is
arguably easier to merge with newer dh_make template files (if one
were to do that ..). The reason to not leave them around is that not
doing so indicates some level of familiarity
Sandro Tosi [EMAIL PROTECTED] wrote:
No, I'm not sure at all! :) I suppose that field should tell the
package builder Ehi, use debian policy version XXX while building
this package and so every script involved will use this information
to validate the package against the d-p specified.
No.
Norbert Preining [EMAIL PROTECTED] wrote:
that it can be backported to woody (sarge already has tetex3).
... on http://www.backports.org/!
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Andrea Bolognani [EMAIL PROTECTED] wrote:
Rhinote is designed to be keyboard friendly, that is, every single action
is bount to a specific keystroke.
^
bound
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Andrea Bolognani [EMAIL PROTECTED] wrote:
Rhinote is designed to be keyboard friendly, that is, every single action
is binded to a specific keystroke.
^^
bound
(I'm not a native English speaker, though)
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Gerber van der Graaf [EMAIL PROTECTED] wrote:
I am trying to repair the libgpiv package I've build. The
libgpiv_0.3.2-1_i386.deb contains a configuration file /etc/gpiv.conf,
as reported by dpkg -c. Extracting the .deb to tmpdir/ (with dpkg -x)
This shows it is a conffile. This is more
Hello,
I am not quite sure it is the best place to post this, but anyway.
I wrote a Python script to create and manage APT repositories which has
the following features:
- supports repositories with a structure almost identical to that of
the Debian archive, with distributions, the
kamaraju kusumanchi [EMAIL PROTECTED] wrote:
$tree fortranposix-0.1/debian/tmp/
fortranposix-0.1/debian/tmp/
`-- usr
`-- lib
|-- libfortranposix.a
`-- libfortranposix.so.0.0.0
2 directories, 2 files
It seems you are using a debhelper compatibility level (see
Bas Wijnen [EMAIL PROTECTED] wrote:
For all platforms, it says that the compilation was maybe-successful.
That sounds like it could be better. Now I haven't seen anything
successful for other packages either, so perhaps it is simply impossible.
Is there anything I can (and should) do to
Li Daobing [EMAIL PROTECTED] wrote:
If I want to modify the source tarball, for example, I want to delete
the admin/CVS and debian/*.ex in the source, should I modify the version
number, for example, called it 0.4.0pre2.dfsg.1-1 or some other name?
The version number consists of two parts for
Ben Finney [EMAIL PROTECTED] wrote:
Is '/usr/bin/env' part of the POSIX spec? Is its behaviour with regard
to command arguments defined? Where would I find out?
It is part of POSIX:
http://www.opengroup.org/onlinepubs/009695399/utilities/env.html
The problem is not with env, but with
David Clarke [EMAIL PROTECTED] wrote:
Why is it better to have the debian directory separate to the main
tarball? I had a read of the thread a little while ago about the
developers including a debian directory, and am still unsure why this is
neccessarily a bad thing if the person producing
Justin Pryzby [EMAIL PROTECTED] wrote:
You list the build-dependencies as best you know them, and then build
in pbuilder. If it does not build, then you look at the last line,
and figure out what it needs that it didn't have, and add the
appropriate thing. If it does build, then you remove
Michelle Konzack [EMAIL PROTECTED] wrote:
I asume, that
rm -f /var/log/tddyndns/-??.log
should work in all shells, because the logs are -MM.log.
It should work in /bin/sh.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13
--
Florent
--
To
Justin Pryzby [EMAIL PROTECTED] wrote:
Note that there was a relevant thread on -devel around about last
October. Someone complained that their thesis was in /var/log/apache/
and was deleted when they purged the package. As such, you might
consider something like rm -f
In case Justin's mail didn't answer all your questions...
Shachar Shemesh [EMAIL PROTECTED] wrote:
Well, you would need a helper program to actually change it, as the
password is encrypted. Otherwise, yes it's a configuration file.
Well, the line is a bit blurry here, I admit. Note that
Shachar Shemesh [EMAIL PROTECTED] wrote:
After your explanation, the only thing I still have doubts over is
whether the files should not go into /var/cache instead.
Erm, which files?
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
Shachar Shemesh [EMAIL PROTECTED] wrote:
The slight dilemma is whether /var/cache or /var/spool would be a
better choice. I'm leaning towards spool, as they tend to be big, and
it would really be better not to erase them.
Well, if you ask me, I think /var/cache doesn't look that bad for this
Shachar Shemesh [EMAIL PROTECTED] wrote:
two questions:
1. My package has a password file. Where is the best place to store it?
/etc/name/password? /var/lib/name/password?
If the password file is a system configuration file (i.e., a file that
can be customized by the admin to modify the
Justin Pryzby [EMAIL PROTECTED] wrote:
In fact, I believe all symlinks should be relative, except top-level
symlinks. And packages probably shouldn't ship any of those:)
Not exactly. cf. Policy § 10.5:
,
| In general, symbolic links within a top-level directory should be
| relative, and
jano kupec [EMAIL PROTECTED] wrote:
3) I think you should build-depends on qt3-dev-tools and not only on
the libs (as you need qmake from the former).
i added it there, but i thought it shouldn't be necessary since the
libqt3-mt-dev already depends on qt3-dev-tools, according to apt-cache
Don Armstrong [EMAIL PROTECTED] wrote:
The author(s) can spend free time in any way the author(s) wish to.
I'm glad to learn that.
Likewise, Blars and myself are free to tell authors that what they
have written appears to be a waste of their time when Free alternative
foo exists. Just like
Foreword: you're lucky I happened to relate your mail to mine. Please do
the necessary so that your future messages actually appear as replies to
the messages you are replying to (hint: the References field does the
job).
Richard A. Hecker [EMAIL PROTECTED] wrote:
You used a judgement to say
Blars Blarson [EMAIL PROTECTED] wrote:
In other words, this looks like yet another vaction clone by someone who
didn't bother to read the vacation man page.
IMO, such judgments are not acceptable on public mailing-lists[1]. If
the upstream author felt like writing a program similar to
Frank Küster [EMAIL PROTECTED] wrote:
Yes, technically this works. But then the version numbers do not
correspond at all to the version numbers used by upstream. And you get
in trouble if upstream changes his packaging and distributes all data in
a single tar.gz:
dpkg --compare-versions
Hi,
Anibal Monsalve Salazar [EMAIL PROTECTED] wrote:
Install ssmtp in the chroot.
Or nullmailer. Also, I have created the attached file in the normal
system (not in the chroot) to start the daemon in the chroot when the
system is booted.
local-sid-root-nullmailer
Description: Bourne shell
1 - 100 of 137 matches
Mail list logo
