be 'enough' but I believe this would also shift
the burden of the work to each and every image designer, so in a way this feels
like a workaround with the main purpose of removing load from base-passwd
maintenance while putting load on everyone else forever :/
Roland Clobus has put a l
n data.
>
> These URLs should also work for any virtual hosts on the Debian
> system, unless the administrator has chosen to not include the
> Debian content on a virtual host.
I'd really like the possibility of having one application have its
own vhost that it may manage for itself.
Roland.
--
Roland Mas
prw-r--r--1 root root0 Jan 1 1970 This-is-not-a-pipe|
h that one needs to remove them for the
source package to be acceptable in Debian (main).
> As far as i know, the problem is that our packaging tools cant handle
> the common tar.bz2 format, or having seperate patches.
Not only.
Roland.
--
Roland Mas
Bonjour, je suis un virus de signature. Propagez-moi dans la vôtre !
w ids with their name deliberately misspelt).
Tools are broken (or so it's claimed, although I have yet to see
evidence of that -- or of the contrary), policy is broken. Both need
to be fixed.
Roland.
PS: Devanagari does look nice, but why the multipart/mixed?
Especially in a thread about ut
word processors
>
> + Educational
> +
> + educational and training programs
> +
> Emulators
>
> wine, dosemu, etc.
>
> I'm looking for seconds for this proposal.
I hereby s
nuity and logic
>
> + Simulation
> +
> + real world simulations, like flight simulators
> +
> Sports
>
> games derived from "real world" sports
I hereby second this proposal.
didn't get any
interesting answers, maybe you didn't ask the appropriate people.
In this case, I'd suggest debian-mentors rather than
debian-policy. Maybe even debian-devel.
Roland.
--
Roland Mas
Why did the elephant cross the road?
Because it was the chicken's day off.
Package: debian-policy
Version: 3.5.9.0
Severity: minor
Hi,
in 6.5. -> 4., 2nd paragraph, s/contains/contain/
bye,
Roland
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux atari 2.4.20 #1 Fri Apr 4 11:15:24 CEST 2003 i686
Locale: [EMAIL PROTEC
throughout the document.
bye,
Roland
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux atari 2.4.20 #1 Fri Apr 4 11:15:24 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
all files, including previously rotated ones. A way around this
is to use the olddir directive or a more exact wildcard (such as
*.log).
bye,
Roland
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux atari 2.4.18 #1 Thu Feb 20 18:57:0
osal, but I won't second it as is.
Going directly from a "may" to a "must" is too quick in my opinion.
Please make that a "should" first. It'll still allow you to file bugs
(although not serious ones), and it'll have a better chance of being
accepted.
ne and we know how many changelogs need to be fixed,
>> but I think in the long run it ought to be mandatory.
>
> Ok, fair enough. Here's a patch which makes it a "should". Given
> my sample with lintian though, I don't think we'll have too many
> package
; -
> -
> -
> -
>
> Preferred documentation formats
>
>
> This way, by removing the requirement that packages must maintain
> symlinks in /usr/doc, we are in fact allowing new packages not to
> fiddle with symlinks anymore.
>
> I'm looking for seconds for this proposal, which is *just* to stop
> requiring symlinks.
Re-seconded.
--
Roland Mas
How does an octopus go into battle?
Fully-armed.
pgpe3gbrkLpo1.pgp
Description: PGP signature
Santiago Vila (2002-07-22 12:02:56 +0200) :
[...]
> I'm looking for seconds for this proposal, which is *just* to stop
> requiring symlinks.
Seconded.
Roland.
--
Roland Mas
ar c t e l l ièu ai ia mi.
-- Signatures à collectionner, série n°1,
Joey Hess (2002-07-20 12:56:10 -0400) :
> So would anyone murder me if the code in debhelper to make postinst
> scripts manage /usr/doc links just went missing?
I wouldn't. And this is a second.
Roland.
--
Roland Mas
Un clavier azerty en vaut deux.
pgpTKbZSRcLyw.pgp
Descr
There's only one second.
> We either need a second second (as it were), or we need some policy
> editor to decide that a change of this nature doesn't require seconds
> (a more reasonable approach IMO), and just to fix it.
I hereby second this proposal.
Roland.
--
Roland Mas
A
Tille, Andreas (2001-09-05 14:16:43 +0200) :
> I wonder why
>
> /usr/share/doc/mozilla-browser/MPL-1.1.txt.gz
>
> is not in this list, was it removed from sid?
non-us?
Roland.
--
Roland Mas
If you spit in the air, it lands in your face.
-- Tevye, in Fiddler on the roof
t;, you have the option of following the terms and conditions
| either of that version or of any later version published by the Free
| Software Foundation. If the Program does not specify a version number of
| this License, you may choose any version ever published by the Free Software
| Fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I hereby second this proposal.
Sourceforge needs Mailman, and Mailman needs these images. Neither
Sourceforge not Mailman should have to be aware of all the available
HTTP servers and change their configuration files.
Roland.
- --
Roland Mas
re than I have until now.
I'm afraid I cannot GPG-sign this message (laptop, see signature),
but if need be I can repost it in a few days when back home.
Roland.
--
Roland Mas
Currently in Bordeaux for the Debian Conference One and the second
Libre Software Meeting.
Radovan Garabik (2001-06-07 16:58:31 +0200) :
> submitted to BTS but since master is down, I am posting a copy to
> debian-policy as well
With the exception of the already mentioned typo, I second this
proposal.
--
Roland Mas
Using a big hammer without caution can cause big
Marco d'Itri (2001-06-01 14:00:34 +0200) :
> On Jun 01, Roland Mas <[EMAIL PROTECTED]> wrote:
>
> >Excuse me? "With the possible exception of the CJK community"? What
> >about people speaking (and writing/typing) Arabic, Hebrew, Greek,
> >Russ
justified affirmation and a not
more justified "deal with it". Thanks.
Roland.
--
Roland Mas
C'est un type qui rentre dans un café. Plouf.
into each emacsen?
Why merge? Just make all the emacsen packages depend on mule-ucs.
Roland.
--
Roland Mas
In every life you got some trouble, when you worry you make it double.
-- in Don't worry, be happy (Bobby McFerrin)
in ``this'' crontab. If MAILTO is
defined (and non-empty), mail is sent to the user so
[...]
-- Paul Vixie, in "man 5 crontab"
--
Roland Mas
[...] Des fois, y'a des trous. -- (Ptiluc)
-- Signatures à collectionner, série n°2, partie 3/3.
which they installed fonts.
Tscho
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
y evaluated).
> If there will be no good reasons against this, I'll work on a
> proposal. Comments? Ideas? Suggestions?
I dislike your idea.
Tscho
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
pgpZYEzxxfatv.pgp
Description: PGP signature
superior approach.
IMHO libc should handle its various incompatibilies itself, because
its a problem in libc, not in the daemon packages.
Tscho
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
iblockfile for MUAs until this problem
is solved (see Bug #43491).
Tscho
Roland
BTW: Can someone explain me, why a mailbox should has to be group mail
writable? Are there any MDAs, which don't run with root
permission? With procmail installed, I can safely change the
lts files of old packages
and to create any symlinks. Okay, I see, that it is more work for
you, because you have to implement this fallback mechanism into the
xlib, but this way sounds much more solid to me than the symlink hack.
Tscho
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
pgpWTMp0kSvdi.pgp
Description: PGP signature
s standalone documentation should be installed under
> + /usr/share// and symlinked to /usr/share/doc//.
Seconded.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
pgpvySwmSJDhn.pgp
Description: PGP signature
vide the header file in the appropriate place, with
> a comment in Readme.Debian.
And why can't you write this into a man page? BTW: the upstream
maintainer will be happy, if you help him writing the documentation,
so he can concentrate on improving the program.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
is no
real man page available for the corresponding executable.
> So, I thought I'd bring the matter up here. If enough people on
> this list agree with me,
I fully agree!
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
pgpeD95jPNNxO.pgp
Description: PGP signature
dentical files in the distribution".
> Note also that the building of slink packages is only one advantage
> of doing things this way.
So you should mention the other advantages, I personally only see the
disadvantages...
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
.
I don't like your proposal, because I don't think, that it solves the
problem (alternatives are mentioned above) while it causes new problems.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
Except this, I begin to like your
proposal...
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
n
pages (including those with undocumented.7 symlinks). It's a bug, so
it's okay to let lintian report this bug until someone provides a real
man page.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
ased before you are allowed to
write bug reports against packages, which place their documentation in
a dictionary /usr/doc/.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
re the release of potato!
You should only file bug reports against packages, which place their
documentation in /usr/share/doc/ _without_ a symlink to
/usr/doc/ (I didn't check which packages still have this
bug).
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
package list (or let some program do
this), which packages enhance the package foo. I'm not sure, whether
this is really a step forward.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
pgpshGZfsUgz6.pgp
Description: PGP signature
severity 43529 fixed
thanks
On Thu, 26 Aug 1999, Roland Rosenfeld wrote:
> Package: debian-policy
> Version: 3.0.1.1
> Severity: important
>
> Policy says the following about the locking of mail:
>
> All Debian MUAs and MTAs have to use the `maillock' and `ma
y to find the documentation, but I'm not sure whether this
is worth the effort (especially when I think, that many Debian
maintainers don't write man pages for all their programs, which means
that there will be many packages without man page). So dlocate -L (or
dpkg -L) will still be th
t; and
it is a much more intuitive place for icons which are used by a window
manager (for example using the menu package) or something like this.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
pgprLTwABVBZN.pgp
Description: PGP signature
ockfile (see footnote [2]) will be the right place to look for
it.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
eports about missing manual pages,
> > + you should inform the user, that you know about the missing
> > + manual page in
> > + /usr/share/doc/package/TODO.Debian.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
oing a dpkg -L. I see a manpage
> for a certain command and do a "man xxx". Result is a "undocumented"
> manpage. Very irritating. It would have saved some effort if there simply
> were no manpage.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
which implements the above noted non blocking mechanism
> > without blocking).
Maybe we should say "liblockfile version >> 1.01" until there is no
new version available yet?
Miquel, what are you thinking about this?
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
that we can bring this into policy before potato is frozen,
because the actual policy in combination with the actual liblockfile
reference implementation will imply mail loss with Linux kernel 2.2.*
on the client machine.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP
" for more information.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
--- - Wed Sep 29 17:59:06 1999
+++ policy.sgml Wed Sep 29 17:58:32 1999
@@ -2722,7 +2722,11 @@
are some people outside which may have missed the
tech-ctte decision (for example the debmake package).
> As for the technical implementation of the tech-ctte decision, I
> propose we use joeyh's implementation found in any recently uploaded
> debhelper package.
Sounds reasonable.
proposed a policy change to make the problem clearer
(#43651, don't ask me, why only Joey Hess seconds this now).
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
if (do_dotlock (path) == 0)
return 0;
do_fcntl_unlock (fd);
}
sleep (rand() % 10);
}
return -1;
}
Ciao
Roland
was told to
switch to knfs, when the server runs 2.2.*.
But 2.2.* on the client and 2.0.* on the server (with the userland
server) works perfectly well, if the attached patch (by Olaf Kirch) is
applied to the client's kernel (with "nolock" in the mount options).
Ciao
R
*). So maybe someone else wants to
compile this list? Or maybe someone knows what the most often used
order of these locking methods is or wants to define "our" preferred
order?
Ciao
Roland
-- System Information
Debian Release: potato
Kernel Version: Linux spinnaker 2.2.11 #1 Don Aug 19 22:41:08 CEST 1999 i586
unknown
ere tools as update-rc.d can work as expected seems
> to be a better approach than the ones described above.
Maybe.
I propose to use /etc/init.local and extend update-rc.d with an option
-l to use /etc/init.local instead of /etc/init.d.
That would be a way, that I could accept.
Ciao
on is: Where do we need this for?
For backup reasons and the like it doesn't make much difference
whether the local init scripts are in /etc/init.d or /etc/init.local.
And if you like to make the local scripts distinguishable, why don't
you simply name them local.foo and place them in
are started in /etc/init.d).
> So you'd put your scripts in /usr/local/etc/rcS.d
Maybe you missed the idea of using different sorting numbers for
different init scripts?
I don't see why there should be any discrimination of local init
scripts, which only can be executed i
places...). I don't see
why I should not place local init scripts in /etc/init.d and only one
/etc/runlevel.conf (the file-rc alternative to /etc/rc?.d/*) gives me
a chance to coordinate all init scripts instead of having 2nd class
scripts in /usr/local/etc/init.d.
Ciao
Roland
--
* [E
ion details of the other method, implemented in the
> + file-rc package, please refer to the documentation of
> + that package.
I fully second this proposal (except the little update-rc.n typo
above).
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
parts of the documentation...
So the above noted idea works when run by hand, but I'm not sure,
whether a postinst script is able to do this job without problems on
_every_ Debian system...
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08D
ke this and I personally try to fix problems as soon as possible,
but some maintainers seem to need much more time for their packages.
> I think the argument of ease of transition for the _user_ is a
> better one.
Me too.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.
creating/removing the "links".
I fear that a complete rewrite of this section makes it much harder to
understand the essentials of this, so we may stay on this "picture" of
symlinks, which describes the idea of the functionality.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
kages using /usr/doc are currently buggy because
> we have already accepted FHS, this means potato will have less bugs
> if we do not make any symlinks.
It's only a question of definition. If we define /usr/doc/ to
be a acceptable for the transition period, this is not a bug.
Ciao
e symlinks manually (without using
update-rc.d) in postinst.
So I (as the actual maintainer of file-rc) second your proposal, to
change the policy in a way, that forbids to create the symlinks in a
way different to update-rc.d.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
stinst:
if [ -d /usr/doc ]; then
ln -s ../share/doc/ /usr/doc/
fi
And in prerm:
if [ -L /usr/doc/ ]; then
rm /usr/doc/
fi
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
pgpzEMePgwIFm.pgp
Description: PGP signature
oc//changelog.gz' (this can be created by
> > > `lynx -dump -nolist').
> I have 3 seconds and no other discussion. Do we have a consensus?
> Speak up if you have a problem with the proposal.
I always wondered, why this wasn't the policy before.
=> Seconded
Ciao
r me as a user.
But it seems that I am the only one who has a problem with this, so
maybe I should simply sleep for approximately a year, hoping that
everything is converted to FHS in this time...
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7
elease "light" goal, like this: "Every package
documentation can be accessed as /XXX/" (where XXX is a
constant for _all_ packages). This was true for slink and I think it
should be true for potato, too. Otherwise potato will be worse than
slink and IMHO we shouldn't step bac
things to /usr/share/doc, as it's trivial change in the rules file.
Correct. But I want to have some kind of smooth migration which isn't
possible if you simply install the documentation of new packages in
/usr/share/doc without any other changes like the symlinks above.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
out uploading
all packages (with the symlink removed) again.
But at the moment I don't fully know how to do this in detail. We
should find a solution for this (which could be supported by
debhelper) soon.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
directory, which I don't like. Yes, I know I
could create another alias for viewing a package copyright and a
package changelog, but this isn't as comfortable as it was before when
using the TAB-completion mechanisms of tcsh or bash.
As long as there are alternatives which annoy the user le
t want it on *your* computer, but
> what is wrong with that track as a default for Debian?
See above (or tell me what other symlink you are talking about).
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
pgpKta0Z7BDil.pgp
Description: PGP signature
etter solution yet (other ideas intend to tell the
web sever to search both directories, but this doesn't help the user
who is searching the correct directory).
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
still available
as /usr/doc/ and in the far future as
/usr/share/doc/) and also web servers can access the
documentation (you have to enable "follow-symlinks" or something like
this for /usr/doc, but this may be already needed, because of the
/usr/doc/ -> /usr/doc/ symlinks which alread
s great that logrotate is now the official way to rotate log files.
Should we make the logrotate package a "required" package now or
should every package using it, "Depend" on it?
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7
On Mon, 28 Jun 1999, Hamish Moffatt wrote:
> On Mon, Jun 28, 1999 at 12:06:53AM +0200, Roland Rosenfeld wrote:
> > But this doesn't solve the other problem: dpkg -L shows these
> > symlinks as real man pages. This is annoying at least for me...
> But why on earth are you l
ows these symlinks
as real man pages. This is annoying at least for me...
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
/var/state, in /var/lib again.
So I fear, that we have to change the packages using /var/state again
to use /var/lib.
Tscho
Roland
PS: I personally prefer /var/state, but that's a different question.
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D
man on all available man pages to find out how the programs are
working. And with this it's very annoying to only see undocumented(7)
instead of useful man page or of seeing that there is no man page
available and I have to keep searching for other documentation.
> In the latter
he
technique who to write a man page. This sounds to be complex, but have
a look at the Man-Page-mini-HOWTO and/or man(7) and you will see, that
writing man pages is quite easy (you can learn this in an hour).
Okay, sometimes it takes some time to maintain a package and write a
man p
te a bug report about this. As we have
seen in the past, this doesn't work (many maintainers simply create
the symlink to stop lintian yelling, but no bug reports were
filed).
So I think that the undocumented.7 symlink is no longer useful and
should be removed from policy.
Ci
ntainers are more likely to respond to a
> bug report from a user of the package than they are to do it on
> their own initiative. Once they receive said bug report, if they
> can't/won't write a man page, they should add that to TODO.Debian...
Do you see a difference to my propo
pages and
I don't see, why we should expose the dh_make template here...
On the other hand, I'm not sure, whether we need this guiding (telling
the developer that it isn't hard to write a man page and where to find
examples) in the policy document?
Ciao
Roland
--
if there simply
> were no manpage.
I hope, that my changes fix this problem and clarify the question
whether a missing man page is considered as a bug.
Ciao
Roland
ual-package-names-list.text:
translation-dictionary Translation word lists in /usr/share/trans/xx-yy
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
ct. This file should especially note _all_ missing man pages in
the package.
But this file shouldn't be able to silence lintian. Maybe it could be
able to lower the level from an error to a warning in lintian...?
> The only really tricky bit I see with this idea is the transition
> from wh
I see a
> manpage for a certain command and do a "man xxx". Result is a
> "undocumented" manpage. Very irritating.
I run into this problem very often, too.
> It would have saved some effort if there simply were no manpage.
So what about simply removing the paragraph a
ould provide a man page and if there
isn't any, this is a bug which should be reported.
> does not the Debian maintainer have the right to agree with the
> upstream author about it not being a bug?
No, he doesn't have that right. He only has the right to ignore the
bug report (hop
ese bugs shall be closed if reopened, unless a clarification of
> policy is sought in the appropriate fora.
The policy is quite clear for me, but as long as you see this in a
different way, we may discuss this in debian-policy (I sent a Cc there).
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
ual package here that every
translation dictionary provides. I propose the virtual package name
"translation-dictionary" for this.
Any objections against this proposals?
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
90 matches
Mail list logo
