On Sun, 06 May 2001, Anthony Towns wrote:
So, here's the deal. We need to get a proper policy for tasks fairly soon.
I agree. The current task-* packages are mostly useless cruft for what they
were supposed to do, i.e. help users during the install.
* There should only be a limited
On Fri, 11 May 2001, Anthony Towns wrote:
--- policy.sgml Sun Apr 29 05:10:09 2001
+++ policy.sgml.std Fri May 11 11:10:09 2001
@@ -1186,9 +1186,9 @@
p
In the source package's ttStandards-Version/tt control
- field, you must specify the most recent
I second this proposal, in the form taken on the message with the msgid
[EMAIL PROTECTED]
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux godzillah.rivendell.sol 2.2.19 #1 Thu Mar 29 19:31:38 BRT 2001
i586
Versions of packages debian-policy depends on:
ii
On Wed, 16 May 2001, Joey Hess wrote:
--- policy.sgml.orig Tue May 15 21:57:25 2001
+++ policy.sgml Tue May 15 22:14:28 2001
@@ -1024,6 +1024,38 @@
/p
/sect1
+sect1
+ headingTasks/heading
+
+ p
+ The Debian install process allows the
On Mon, 14 Feb 2005, Adam Heath wrote:
On Sat, 12 Feb 2005, Bluefuture wrote:
3. submit with a wishlist (tag patch) bug to BTS.
These things shouldn't be filed as bugs, when there are so many. Make a
It is not an one-go mass-bug filling, since he has to review every watch
file anyway. It
On Sat, 26 Mar 2005, Roger Leigh wrote:
Is there a project-wide policy for support for devfs (and devfs-style,
e.g. udev devfs.rules) device naming?
Do it if you can. It is not mandated anywhere, but it is clearly a very good
idea. We should even make it a *may* in policy to stress this, I
On Sun, 03 Apr 2005, Bill Allombert wrote:
For the record:
$ dpkg -L libxine1|grep /usr/share/doc
/usr/share/doc/xine
[...]
Given the binary package 'xine' does not exist currently, I think this
is a policy violation due to namespace breakage.
Agreed. The directory would have to be named at
On Fri, 22 Apr 2005, Russell Coker wrote:
On Sunday 27 March 2005 00:26, Roger Leigh [EMAIL PROTECTED]
wrote:
Is there a project-wide policy for support for devfs (and devfs-style,
e.g. udev devfs.rules) device naming?
The SE Linux kernel code doesn't and won't support devfs. Devfs is
On Fri, 06 May 2005, Joerg Sommer wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Sun, 03 Apr 2005, Bill Allombert wrote:
For the record:
$ dpkg -L libxine1|grep /usr/share/doc
/usr/share/doc/xine
[...]
Given the binary package 'xine' does not exist currently, I think
On Fri, 26 Nov 2010, jida...@jidanni.org wrote:
The Debian Policy Manual should state what the preferred date on manual
pages should be, or wishes upstream would make it.
There is no need. This is documented in man-pages(7). It is the date the
manpage was last revised.
Also mention if
On Wed, 02 Mar 2011, Sean Finney wrote:
Having a warning in lintian for arbitrarily long (perhaps = 256)
filenames is totally reasonable i'd say, but there's no reason to
Most (all?) filesystems commonly used in Debian systems will limit you to
somewhere close to 254 characters per filename
On Sat, 30 Apr 2011, Russ Allbery wrote:
Osamu Aoki os...@debian.org writes:
This is another topic. I do not think everyone agreed yet to a
particular set of numbers. The more I looked into this issue, I think
followings are the possible numbers:
No, but I'd like to have a MUST rule that
On Sat, 30 Apr 2011, Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
I don't think that /etc/shadow qualifies as a configuration file,
either; I would call it variable state information (→ /var/lib), but
it lives in /etc because a) it has to be on the root filesystem, b)
On Sun, 01 May 2011, Henrique de Moraes Holschuh wrote:
On Sat, 30 Apr 2011, Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
I don't think that /etc/shadow qualifies as a configuration file,
either; I would call it variable state information (→ /var/lib), but
it lives
On Sun, 01 May 2011, Bill Allombert wrote:
On Sat, Apr 30, 2011 at 09:00:14PM -0700, Russ Allbery wrote:
So the reason for imposing a length restriction on version numbers in
particular is due to the UI display of aptitude? I'm a bit dubious that
this is a good justification for a Policy
On Sun, 29 May 2011, Nicholas Bamber wrote:
I am managing a package that does 'userdel' in a purge. It removes the
home directory as that contains config files. I am a bit concerned about
I've seen that cause data loss. You must make sure the homedir is
exactly as you set it when you created
Package: developers-reference
Version: 3.4.4
Severity: wishlist
Updates to developers-reference have no regression risk, and unlike
debian-policy, whatever it contained at the time of a stable release is
of little relevance: one really should base his work and interaction
with the Debian project
On Wed, 15 Jun 2011, Michael Biebl wrote:
At the current state, I'm not for adding /run/shm to debian-policy.
If we can get wider acceptance of this feature (cross-distro), then my
position
on this might change. Atm this looks like a Debian-only feature with no real
use-case why we need
On Fri, 17 Feb 2012, Carsten Hey wrote:
The package debianutils already uses such a target and uses 'prebuild'
as name. The developers reference could adopt this name.
How would this relate to Policy 4.14 - debian/README.source?
In general, debian/README.source does not contain
On Mon, 20 Feb 2012, Russ Allbery wrote:
Wouter Verhelst wou...@debian.org writes:
To be a bit more specific on this: such a tool could be implemented
fairly trivially with a dpkg trigger. Just register a trigger that
triggers on any file under /usr/share/doc, and have it call gzip --best
On Sat, 17 Mar 2012, Carsten Hey wrote:
prebuild:
test ! -d wafadmin
./waf --help /dev/null
mv .waf-*/wafadmin .
rm -f .waf-*/t.bz2
rmdir .waf-*
sed -n -i -e '1,/^#==$$/ p' -e '/^#==$$/,$$ p' waf
Maybe this would work?
prebuild: prebuild-stamp
On Sun, 25 Mar 2012, Bill Allombert wrote:
On Sun, Mar 25, 2012 at 09:18:18AM +1030, Ron wrote:
On Sat, Mar 17, 2012 at 04:55:19PM -0700, Russ Allbery wrote:
Jakub Wilk jw...@debian.org writes:
How should packages behave if there is no explicit parallel=N in
DEB_BUILD_OPTIONS? I
On Fri, 01 Jun 2012, Holger Levsen wrote:
They seem to conclude 2
things applying on our cases :
- dpkg-statoverride --list must be used to check if the administrator
allows dpkg to change permissions on the file. For instance an
administrator could set an override before the
On Sat, 23 Jun 2012, Jonathan Nieder wrote:
Russ Allbery wrote:
Would one list bug-gnu-ut...@gnu.org? That's the most useful contact
point (and we have a copyright-format field for that), but it's not in any
real sense the author.
Sure it is --- it's the contact point for the people who
On Tue, 11 Sep 2012, Jonathan Nieder wrote:
Bernhard R. Link wrote:
* Jonathan Nieder jrnie...@gmail.com [120911 05:45]:
The requirements in policy for
debian/rules clean are very stringent --- to avoid the
unrepresentable changes it would be enough to
On Sat, 03 Nov 2012, Bart Martens wrote:
I understand its copyright information and distribution license(s) as
including all licenses, so that the user can still choose between the
alternative licenses. The packager should not choose for the user.
Sometimes we have to. The source may be
On Fri, 09 Nov 2012, Josselin Mouette wrote:
It looks to me that we should strictly favor the transitional package
approach instead. Shouldn’t we entirely forbid the
Provides/Conflicts/Replaces combination way of handling upgrades, except
for virtual packages?
And instantly break even further
** PLEASE CC: ME ON REPLIES **
The new license for AMD microcode updates seems to be quite obnoxious.
Is it acceptable for non-free?
The full license text is reproduced below:
Copyright (C) 2010-2013 Advanced Micro Devices, Inc., All rights reserved.
Permission is hereby granted by Advanced
Sorry about this, I sent it to the wrong ML. Will post to debian-legal.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To
On Sat, 25 Jan 2014, Markus Koschany wrote:
I wanted to clarify that there are also efforts to support both menu
systems and that the majority of games already integrate both.
https://wiki.debian.org/Games/JessieReleaseGoal
In my opinion the policy should at least mention the Debian menu
On Fri, 15 Aug 2014, Michael Biebl wrote:
Am 15.08.2014 17:47, schrieb Gerrit Pape:
Package: rsyslog
Version: 8.2.2-3
Severity: serious
Justification: Policy 2.5
Hi, the current rsyslog package version in testing is priority important
and depends on packages with priority extra.
On Sat, 16 Aug 2014, Charles Plessy wrote:
Le Fri, Aug 15, 2014 at 02:22:33PM -0300, Henrique de Moraes Holschuh a écrit
:
Am 15.08.2014 17:47, schrieb Gerrit Pape:
That this rule is violated in hundreds of cases [1] clearly shows that
there is something wrong which needs
On Tue, 18 Nov 2014, Andrey Rahmatullin wrote:
On Tue, Nov 18, 2014 at 09:24:15PM +0900, Charles Plessy wrote:
I guess that it is implicit from the defintion of contrib that follows in
2.2.2:
The contrib archive area contains supplemental packages intended to work
with
the
On Sat, 22 Nov 2014, Charles Plessy wrote:
Le Fri, Nov 21, 2014 at 10:56:15AM +0100, Bill Allombert a écrit :
What about automatically generated control files and substvar ?
e.g.
Depends: ${misc:Depends}
where ${misc:Depends} resolve to the empty string ?
Does dpkg-gencontrol take
On Sun, 23 Nov 2014, Bill Allombert wrote:
diff --git a/policy.sgml b/policy.sgml
index 6eac491..66de529 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2556,13 +2556,15 @@ endif
example compact=compact
Package: libc6
/example
the field name is ttPackage/tt and the
On Sun, 23 Nov 2014, Jakub Wilk wrote:
* Andrey Rahmatullin w...@debian.org, 2014-11-22, 12:39:
--- a/policy.sgml
+++ b/policy.sgml
@@ -8892,6 +8892,7 @@ fname () {
would point to file/srv/run/file rather than the intended
target.
/footnote
+ Symbolic
On Mon, 24 Nov 2014, Charles Plessy wrote:
Le Sat, Nov 22, 2014 at 08:15:03AM -0200, Henrique de Moraes Holschuh a écrit
:
Empty fields in debian/control must be valid in *source* packages. It is a
widely used feature of the dpkg-dev suite, and it has been around for a very
very long
On Sun, 23 Nov 2014, Bill Allombert wrote:
Anyway, this is a second try.
Cheers,
commit d450ce8f978bad0f3927ea055698b789055dfa3a
Author: Bill Allombert bill.allomb...@math.u-bordeaux1.fr
Date: Sun Nov 23 16:16:21 2014 +0100
Document that empty field values are only allowed in
On Mon, 24 Nov 2014, Charles Plessy wrote:
Le Sun, Nov 23, 2014 at 03:08:47PM -0200, Henrique de Moraes Holschuh a écrit
:
On Mon, 24 Nov 2014, Charles Plessy wrote:
do you have examples of packages having empty fields in source package
control
files ? I have not found any
On Sun, 23 Nov 2014, Bill Allombert wrote:
--- a/policy.sgml
+++ b/policy.sgml
@@ -1928,12 +1928,16 @@ zope.
impossible to auto-compile that package and also makes it hard
for other people to reproduce the same binary package, all
required targets must be
On Sun, 23 Nov 2014, Bill Allombert wrote:
On Mon, Nov 24, 2014 at 02:15:45AM +0900, Charles Plessy wrote:
Le Sun, Nov 23, 2014 at 03:08:47PM -0200, Henrique de Moraes Holschuh a
écrit :
On Mon, 24 Nov 2014, Charles Plessy wrote:
do you have examples of packages having empty fields
On Sun, 23 Nov 2014, Jakub Wilk wrote:
* Henrique de Moraes Holschuh h...@debian.org, 2014-11-23, 18:49:
This bug is mostly to document a check in dak. Are you
suggesting the check is looking at the debian/control file and
reject source packages with empty fields?
That would be broken
On Fri, 19 Dec 2014, Jonathan Nieder wrote:
8.7 RUNPATH and RPATH
Libraries and executables should not define RPATH or RUNPATH unless
absolutely necessary.
This part seems vague to me --- if a project relies on RUNPATH but could
be modified to avoid relying on it, is today's use of
On Sun, 21 Dec 2014, Martin Carpenter wrote:
Packages are not allowed to create *and* execute libraries or executables
with unsafe RPATH or RUNPATH at any time, not even during their build
process.
But actually Package maintainers should not make or run dangerous
stuff? Agreed -- and
On Mon, 28 Nov 2005, Bill Allombert wrote:
So I would propose for policy explicitly forbid 2) and 3).
Agreed. In particular, 3) is a MUST NOT if I ever seen one.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of
On Wed, 30 Nov 2005, Ian Jackson wrote:
Just as one example, a program might reasonably have an rpath in
/usr/local/lib/package/. And there might be other reasons why
Not in Debian, it doesn't. Since policy is about Debian *packages*, and
Debian cannot ship much more than empty dirs under
On Fri, 02 Dec 2005, Ian Jackson wrote:
Indeed, rpath is only acceptable for:
1. dynamically loaded modules/plugins
2. libraries that must live outside of ld.so directories
And these things might reasonably be searched for in
/usr/local/lib/foo as well as /usr/lib/foo.
rpath is for
On Fri, 02 Dec 2005, Ian Jackson wrote:
A sensible way to arrange for this to work might be for
/usr/bin/frobnicate's rpath to specify /usr/lib/frobnicate/modules.
That way frobnicate can load `frictive' without having to specify the
path.
Hmm... (reads ELF 1.2). Oh drat, DT_RPATH is a
On Thu, 29 Dec 2005, Marco d'Itri wrote:
These packages have already been fixed:
rng-tools
Huh? rng-tools certainly takes benefit of MAKEDEV. It doesn't bork if
MAKEDEV has disappeared, though. Is that what you mean?
rng-tools postinst does this:
(cd /dev ./MAKEDEV hwrandom || ./MAKEDEV
On Sun, 08 Jan 2006, Matt Kraai wrote:
According to the LSB Core Specification 3.1, init scripts should
consider running stop on a service already stopped or not running
successful, but the example in policy does not behave this way because
it does not pass --oknodo to start-stop-daemon in the
On Mon, 23 Jan 2006, sean finney wrote:
is my interpretation of this correct, or am i over-analyzing things?
As I have already told you, yes, you ARE correct, and yes, anyone restarting
stuff in the reload target has a bug in their packages.
--
One disk to rule them all, One disk to find
On Mon, 03 Apr 2006, Lars Wirzenius wrote:
Current policy states in section 9.3.3.2 (Running initscripts) the
following: The use of invoke-rc.d to invoke the /etc/init.d/*
initscripts is strongly recommended[51], instead of calling them
directly.
Footnote 51 further says: In the future,
On Mon, 05 Jun 2006, Lars Wirzenius wrote:
The policy manual says (9.3.2 Writing the scripts):
The init.d scripts should ensure that they will behave sensibly
if invoked with start when the service is already running, or
with stop when it isn't, and that they don't
On Wed, 21 Jun 2006, Gerrit Pape wrote:
On Mon, Jun 05, 2006 at 03:36:30PM +0300, Lars Wirzenius wrote:
The policy manual says (9.3.2 Writing the scripts):
The init.d scripts should ensure that they will behave sensibly
if invoked with start when the service is already
On Mon, 26 Jun 2006, Gerrit Pape wrote:
Instead of writing their pid to a file, daemons could maintain a fifo
and read (one-byte) commands from there; if there's no reader on the
fifo, the daemon isn't running and nothing bad happens.
Agreed.
Or better yet, instead of duplicating such code
On Mon, 10 Jul 2006, Sven Mueller wrote:
I think we need something like a policy to be, i.e. some document
which shows which changes _should_ go into the policy document as soon
as packages are fixed accordingly. Something that results in an
We can have a ongoing tasks page in the wiki, and
On Wed, 09 Aug 2006, sean finney wrote:
Thanks to the work of our DPL Anthony aj Towns (and all the other
people who have worked on this without my knowledge), I am happy to
announce that dak, our archive management software, finally supports
the use of the tilde ('~') in version
On Wed, 09 Aug 2006, Manoj Srivastava wrote:
Policy documents reality, so if now the reality is that ~ is
supported and its use is encouraged, then yes, policy should be
changed ASAP.
No. Policy documents what is correct, not just any old broken
thing that is currently being
On Thu, 14 Sep 2006, Steve Langasek wrote:
The BIG problem is how to get the next-version. Say you have version
1.2-3. A binNMU would be 1.2-3+b1, a security release would be
1.2-3etch1 (unless there was a binNMU).
In the Great Scheme, these were supposed to become 1.2-3+etch1 instead of
On Thu, 05 Oct 2006, Bill Allombert wrote:
\usepackage[shameless]{plug}
\begin{plug}
I have proposed a (IMVHO) better solution to the
config.sub/config.guess problem see
http://lists.debian.org/debian-science/2006/03/msg00038.html
\end{plug}
You know, I'd have appreciated getting that email
On Tue, 12 Dec 2006, Michelle Konzack wrote:
Am 2006-11-27 13:02:18, schrieb Michael Stone:
On Mon, Nov 27, 2006 at 05:33:25PM +0100, Michelle Konzack wrote:
And HOW can I get UID's =65536 to work?
I have already tried it in my /etc/passwd and
/etc/group but it gives tonns of errors.
On Mon, 11 Feb 2008, Kapil Hari Paranjape wrote:
Note that if the upstream's auto-generated files are deleted during
the clean target, then the source *must* be re-packaged to avoid
needless clutter in the .diff.gz which is of a negative nature.
Not so. Deletions are ignored. Ever tried it?
On Fri, 04 Jul 2008, Raphael Hertzog wrote:
Here's a try (against current master branch):
diff --git a/policy.sgml b/policy.sgml
index c9bd84f..772afce 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -5946,9 +5946,11 @@ rmdir /usr/local/share/emacs 2/dev/null || true
The
On Fri, 13 Feb 2009, Russ Allbery wrote:
I went to write the patch for this, but I paused when I saw that the other
part of this sentence (explicitly running such scripts with sh at other
run levels) is implemented. The current /etc/init.d/rc runs the script
directly if it doesn't end in .sh
On Fri, 11 Sep 2009, Manoj Srivastava wrote:
Looking at the bug report, it seems like we agree that the
current policy is correct, and the should should not be changed to a
must? In that case, can we just close this report?
Alternatively, the proposal should be clarified to mention
Package: debian-policy
Version: 3.5.6.0
Severity: minor
The debconf specification text says:
The config-file contains a new element, which I call the configmodule.
This is a program that will determine the configuration before the package
is unpacked. This means it is run before the
On Fri, 08 Feb 2002, Joey Hess wrote:
Henrique de Moraes Holschuh wrote:
Please document this, it may save someone a grave bug someday, and maybe
even avoid a lot of headaches.
Does it really need to be documented in policy? debconf-devel(8)
Well, one need not document that in policy
On Wed, 29 May 2002, Matthias Klose wrote:
Ok, now that we separate woody and unstable, it is time to think about
this. IMO, this is not a gcc only thing. So propably it should be
changed in dpkg/policy first. debian-cpu-linux-gnu and
cpu-linux-gnu come to mind as an alternative.
Ben
On Sat, 01 Jun 2002, Marcus Brinkmann wrote:
Do please notice we have (at least) *TWO* classes of arch identification
strings. What RMS seems to be asking us to do is to change all of them to
have '-gnu'. That is *NOT* what I am talking about.
Actually, RMS is concerned about the
On Wed, 12 Jun 2002, Wichert Akkerman wrote:
Previously Branden Robinson wrote:
2) The examples advise people to redirect the output of update-rc.d to
/dev/null. Adam Heath and I feel this is a bad idea, and even if this
change is not made, some people (like the author of lintian; see Bug
On Sun, 14 Jul 2002, Bernd Eckenfels wrote:
After short discussion on debian-devel it is obvious, that the section on
policy about the restart and force reload of daemons in init.d scripts could
I agree with that. We do not define what force-reload does if the service
is not running [and it
On Mon, 22 Jul 2002, Joey Hess wrote:
So can we get something in policy about invoke-rc.d now? I'm chomping at
Yes, please apply the already approved stuff. policy has been unfrozen,
now...
I will send to this list before tomorrow a new prolicy proposal to account
for the transition from
On Sun, 18 Aug 2002, Richard Braakman wrote:
This would lose a feature that I find valuable: usually, recompiling
a package with the debug option will generate a binary whose symbols
are compatible with the normal packaged binary. I have used this
several times to chase down hard-to-find
On Mon, 19 Aug 2002, Oliver Elphick wrote:
Are we still supposed to maintain the /usr/share/doc/x - /usr/doc/x
link for uploads to sarge?
No.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the
On Mon, 19 Aug 2002, Joey Hess wrote:
Of course policy still says we must. I don't know when we want to change
that; now or when a lot of packages have stopped including it, or what.
Well, if we simply change policy not to say anything, then including it is
not against policy.
Later we forbid
As it was talked in Debconf2, we would be better off if we renamed all
*-rc.d utilities (invoke-rc.d, policy-rc.d, update-rc.d) to rc.d-*
(rc.d-invoke, rc.d-policy, rc.d-update).
Transition plan:
1a. Rename all scripts to their new names, add compatibility symlinks to
the sysvinit and
On Sun, 08 Sep 2002, Chris Waters wrote:
First, I'd like to say that I'm fairly neutral in this debate. None
So am I, actually. I am proposing it because I said at debconf2 that I
would, after the people there got convinced it would be a good thing by
whomever proposed it.
1. Since we'll be
On Tue, 10 Sep 2002, Chris Waters wrote:
~ $ grep update-rc.d /var/lib/dpkg/info/*{pre,post}{inst,rm}|wc -l
88
If you use update-rc.d, you will call init scripts with 99.9% probability.
That means you _will have to_ switch to invoke-rc.d (sooner or later
anyway). For people using
On Wed, 11 Sep 2002, Bill Allombert wrote:
I feel it is very important every init script behave the same. However the
wording of section 10.3.2 is confusing:
The init.d scripts should ensure that they will behave sensibly if invoked
with start when the service is already running, or
On Thu, 12 Sep 2002, Oliver Elphick wrote:
On Thu, 2002-09-12 at 18:43, Robert Bihlmeyer wrote:
Starting and stopping a service should be idempotent, i.e. further
attempts should silently succeed.
I don't agree with that, if that is what current policy says (but I
don't think it does).
On Thu, 21 Nov 2002, era eriksson wrote:
--- 5823,5835
p
Any configuration files created or used by your package
must reside in tt/etc/tt. If there are several you
! should create a subdirectory of tt/etc/tt
named after your package./p
I
On Wed, 04 Dec 2002, Michael Lamertz wrote:
Except for core packages, that shouldn't happen, since packages install
Then any proposed solution should take that into account...
Josip Rodin suggested on debian-policy that I should file a bug report
against the package that contains
On Thu, 05 Dec 2002, Michael Lamertz wrote:
Oh dammit, do we really have to enter these dark lands...
Apparently. Let me get my scuba suit, and a harpoon...
On Wed, Dec 04, 2002 at 09:49:17PM -0200, Henrique de Moraes Holschuh wrote:
the module which works perfectly well on, ... well
On Wed, 11 Dec 2002, Bill Allombert wrote:
Here a patch that clarify the behavior of /etc/init.d/foo restart.
This is taken straight out of
LSB 1.2 / Chapter 22. / System Initialization / Init Script Actions
--- policy.sgml 2002-11-15 07:49:40.0 +0100
+++ policy.sgml.new
On Fri, 07 Mar 2003, Wichert Akkerman wrote:
Previously Stephen Frost wrote:
We need to make a decision on how to properly handle multiple library
versions ending up linked into the same process.
I think what we should do is simple: 'do not do that'.
We have been very bad on that
On Sun, 09 Mar 2003, Sam Hartman wrote:
I think that we should implement versioned symbols.
Anthony Uhh, versioned symbols means that programs built on
Anthony Debian systems won't run elsewhere. That's not something
Anthony we should be doing, except in very specific cases
On Tue, 11 Mar 2003, Anthony Towns wrote:
On Mon, Mar 10, 2003 at 10:47:40AM -0300, Henrique de Moraes Holschuh wrote:
Agreed. As far as programs build on Debian systems won't run elsewhere,
it is just a matter of pushing the versioning of said core libraries to the
LSB, which shouldn't
On Wed, 12 Mar 2003, Anthony Towns wrote:
On Tue, Mar 11, 2003 at 10:47:34AM -0300, Henrique de Moraes Holschuh wrote:
It doesn't need to, either. Whatever isn't in the LSB doesn't matter as far
as interoperatibility is concerned [if the LSB is done right].
Uh, libqt isn't standardised
On Wed, 12 Mar 2003, Junichi Uekawa wrote:
That is caused by dlopen used by PAM, which I assume is caused by
Or dlopen used by glibc (nss modules), or dlopen used by anything else.
Apache modules can kill apache that way too, for example (afaik anyway).
dlopening with RTDL_GLOBAL, where there
On Thu, 20 Mar 2003, Junichi Uekawa wrote:
I consider the following portion may be suitable for inclusion in the
policy; if it is more precisely worded:
If library or application dlopens a module, that module and its chain of
dependencies have a chance of being loaded in two versions at
On Fri, 25 Apr 2003, Joey Hess wrote:
I suggest we add the following to policy section 11.4.
(Wording by Bill Allombert.)
When scripts are installed into into a directory in the system PATH,
the script name should not include an extension such as .sh or .pl
that denotes the
Hi Bill!
On Mon, 28 Apr 2003, Bill Allombert wrote:
On Mon, Apr 28, 2003 at 11:56:24AM +0200, Santiago Vila wrote:
As per the discussion on debian-devel, I am filing this bug with patch
to have base-files create the /run directory. To summarise the
discussion, we need to move program
Hi Bill!
On Mon, 28 Apr 2003, Bill Allombert wrote:
On Mon, Apr 28, 2003 at 01:51:31PM -0300, Henrique de Moraes Holschuh wrote:
Hi Bill!
As per the discussion on debian-devel, I am filing this bug with patch
to have base-files create the /run directory. To summarise
Hi Bas!
On Mon, 28 Apr 2003, Bas Zoetekouw wrote:
Hi Bill!
You wrote:
Thanks a lot! I will try to improve it again:
As an extension to the FHS, the Debian filesystem has a /run directory
intended to hold program state file for programs that run early during
the boot
On Sun, 08 Jun 2003, Wouter Verhelst wrote:
[EMAIL PROTECTED]:~$ echo $LANG
nl_BE.UTF-8
Is it in locale.gen? Otherwise, you will NOT have the locale information...
which means that uxterm manually ensures that $LANG is set to
something.UTF-8, since I set my $LANG to nl_BE.
Ick.
--
One
Hi Colin!
On Mon, 09 Jun 2003, Colin Walters wrote:
On Mon, 2003-06-09 at 12:05, Henrique de Moraes Holschuh wrote:
On Sun, 08 Jun 2003, Wouter Verhelst wrote:
[EMAIL PROTECTED]:~$ echo $LANG
nl_BE.UTF-8
Is it in locale.gen? Otherwise, you will NOT have the locale information
On Mon, 01 Sep 2003, Stefan Gybas wrote:
Andrew Suffield wrote:
You can't make it mandatory before you implement it.
I'll implement status for the init script and the changes to the
maintainer scripts in my packages with the next upload. What else should
I implement?
Tested patches
On Tue, 11 Nov 2003, Sylvain LE GALL wrote:
In one of the package i maitain i have a config script which begin by
asking if the service attached to this package need to be run. I use a
variable ( stored in /etc/default/mldonkey -- LAUNCH_AT_STARTUP=yes )
to determine if i need to run the
On Tue, 30 Dec 2003, Dan Jacobson wrote:
Debian should no longer be like some mere arcade kiddie game machine,
where if you don't like the games staring when you deposit your coin,
then sorry.
It is not anymore. This has been fixed by invoke-rc.d. All that remains
now is to give users an
On Sun, 04 Sep 2005, Marc 'HE' Brockschmidt wrote:
Lars Wirzenius [EMAIL PROTECTED] writes:
* Some packages still don't use debconf for prompting, and
instead do silly stuff that assumed it is OK to read and
write /dev/tty.
Actually, the policy explicitly
1 - 100 of 123 matches
Mail list logo
