'll
just fix itself. If the other packages that depend on libc want to
continue to work, then they better comply.
Of course, if they don't want to they don't have to. ;-) But then they'll
just stop working...
--
Brock Rozen [EMAIL PROTECTED]
nfusing".
Excuse me if I don't understand things correctly -- but isn't the purpose
here to restart the daemons? Yes, we'll only do so if they're linked --
but we only care about the linkage *because* if they are then we want them
restarted!
--
Brock Rozen [EMAIL PROTECTED]
cked in any post-woody release -- the woody init script
tells libc6 that it needs a restart.
Besides, I believe libc6 is installed and restarts the daemons even before
most of the new daemon packages (like sendmail) are unpacked and installed
-- such that the restart w
On 17 Oct 2000 at 06:36, Itai Zukerman wrote about "Re: All services that...":
> Why should we assume that only daemons from Debian packages will need
> to be restarted?
We're not. But we can't be expected to know about them as well. (not to
mention interacting wi
Well, then maybe it's time to change the definition of "standard" ?
--
Brock Rozen [EMAIL PROTECTED]
x27;t see 1109 , instead they'd see 100, 200 or n -- depending
on how many versions they haven't upgraded in.
This should make the numbers relative (Which they should be) in the eyes
of the user.
--
Brock Rozen [EMAIL PROTECTED]
typical user doesn't run scripts in /etc/init.d
either
Brock Rozen [EMAIL PROTECTED]
"Bug#36151:...":
> Brock Rozen suggested that init.d scripts should have explicit
> PATH=... settings. No-one commented on the idea.
>
> In general, all programs which make assumptions about PATH containing
> more that /bin and /usr/bin should probably explicitly set PATH; this
No, don't make me back it up. My server works just fine on it's RAID-5
that I don't need back-ups (just one example of why someone wouldn't
back-up; although it don't protect against every type of data loss).
And I still think a configurable uninstall would serve Debian
uninstall
(a.k.a. purge) the packages asks if you want to remove everything or you
want to go it custom and then decide. First option would be what you get
today.
Consistency can only be maintained to a certain level, and if the user is
asking for it to be "broken" (sounds like a holy grail or something) then
there should be nothing wrong with that.
--
Brock Rozen [EMAIL PROTECTED]
o mandatory
(except when it states otherwise).
I say stick it in policy. If a package doesn't conform to policy, then
that's what the BTS is for, among other things.
--
Brock Rozen [EMAIL PROTECTED]
staller that many programs use.
"Auto-Uninstall" and "Custom-Uninstall", with the latter going the way of
the new Debian installation, just the other way around.
--
Brock Rozen [EMAIL PROTECTED]
chnically, possile.
Just a thought.
> willing to accept patches ;-) ). I think there are more important bugs
> in Heimdal (it still under active development) then fixing man pages.
Agreed.
--
Brock Rozen [EMAIL PROTECTED]
f the job to somebody else who is willing to run the process of
accepting new volunteers (a.k.a maintainers).
It just seems that non-acceptance of new maintainers runs against the
whole idea of Debian.
And yes, the reason quoted above is just one of them -- but it should not
be THE rea
Some files should definitely not have permissions for "other" to read them
-- like mail.log and syslog . Both have privacy issues, if not security
issues, involved.
--
Brock Rozen [EMAIL PROTECTED]
copyright
> on the current version is jointly held by all people who have made
> significant changes to the manual.
Exactly mt point -- and thus we end up with a policy that has copy rights
held by so many people that it's ridiculous.
--
Brock Rozen
r ORIGINAL sections that others
> > produced. (Again, I'm not discussing changes they made to his sections)
> >
> > Somebody posted a url on this -- and essentially, that what I'm repeating.
> > I no longer have the url.
>
> Well, someone named Brock Rozen
ebody posted a url on this -- and essentially, that what I'm repeating.
I no longer have the url.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
e document (I
am not talking about sections that have been changed/reworded)
Perhaps requiring all Debian maintainers to agree that policy belongs to
SPI would be the best route of action.
But yes, you still need Ian's approval as the bulk of the policy is
On Fri, 22 Oct 1999 at 16:38, [EMAIL PROTECTED] wrote about "Bug#48045:...":
> I thought about naming it 'crypto', but it would also not describe it
> correctly
> (since we also have packages encumbered by other silly laws there, like
> software patents). Any
letons.com/brad/copymyths.html
I liked http://lcweb.loc.gov/copyright/circs/circ03.pdf or even better,
http://lcweb.loc.gov/copyright/faq.html
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
ven, if at all, to Software in the Public
Interest (as somebody already mentioned) in order to protect it being free
-- and nothing more than that.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
the home directory of each user in a
sub-directory there. Just like ~/public_html is done with Apache.
But if crontab does what it said above -- then is there any need for this?
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services
icense) is that it
might allow modified source to be distributed, where all that needs to be
done (and this could be part of postinstall or whatever) is to compile it.
Thus, we're not distributing modified binaries but modified source and
compiling locally (and automatically).
--
Brock Rozen
On Mon, 14 Jun 1999 at 18:36, Jim Lynch wrote about "Re: Editor and...":
> Brock Rozen wrote:
> > I didn't see support for pico in this -- thus, I'm against this proposal
> > until sensible-editor has pico support. (If I'm mistaken,and it does have
&
n the Pine issue, even though they
hadn't done their homework on it's new license. I would bet they would say
I'm being disruptive -- but had I been a developer, my input would've been
considered appropriate.
So, no, I don't think anything has changed.
--
Brock Rozen
ing -- do we even have a
formal policy on proposals? Yes, Manoj has something...but does policy
refer to it? And is this discussed in Manoj's document? (sorry, haven't
taken a look)
*Steel, non-developer armor protects me the whole time*
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
pgp1NDNG5tpJb.pgp
Description: PGP signature
-- and
since sensible-editor doesn't support it -- I will vote AGAINST this
proposal. It's certainly my right, and my considerations,
whatever they are, are my considerations.
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
cond this. It covers (and expands upon) my proposal, number 36151 in
the BTS.
I like it, and initially it can be kept simple. Please bring this out of
"old" and into "Under discussion".
Thanks!
--
Brock Rozen [EM
nd user-friendly is
always good, as long as it's bug friendly.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
shed out.
I will second this, simply because I like features and this one certainly
can't hurt. I think it should be an option though (to save the time
involved in processing) for those of us who *know* we have enough disk
space available.
--
Brock Rozen
ble-editor.
I didn't see support for pico in this -- thus, I'm against this proposal
until sensible-editor has pico support. (If I'm mistaken,and it does have
pico support, then I will second this proposal).
BTW, this isn't in the BTS (At least, I see no refere
ved by making them run as
root again. So nothing's lost except time -- with a possible gain in
security.
Yes, this is a good ide.a
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
I know the Pine 4.x series has issues with perms on mailboxes.
This needs to be kept in mind.
Brock Rozen
not be closed, regardless of whether the maintainer likes (or
feels the need) for such an item.
Thanks,
Brock Rozen
not read. A pointer is quite sufficient.
If policy is strictly for new maintainers then you're right.
Maybe we need separate policies or maybe the proposal-submitting
guidelines need to be included in the constitution (whatever it's status
is).
--
Brock Rozen
done -- IMHO.
Starting with what Manoj has proposed is great -- we can build from there.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
e itself how it would change itself, but
that's fine; governments work that way, we can as well) ;-)
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
later.
3 months later should be fine (maybe sooner, maybe later; but you
understand the idea)
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
On Fri, 28 May 1999 at 17:14, Joey Hess wrote about "weekly policy summary":
> Md5sum proposal
> * Under discussion.
> * Proposed on 17 May 1999 by Piotr Roszatycki; seconded by Peter S
> Galbraith, Brock Rozen and Christoph Lameter.
> * Require a md5ums file b
I second this proposal.
It deals with the message I sent through yesterday about this section of
the policy.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis
mmon not being "the whole of X" as that term is used in the
second paragraph.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
not provide any security when it comes to
> package integrity checking, or protection against breaches, and they
> leave exposed the most critical parts of the system -- the config
> files.
>
> I think I object to this proposal on technical grounds.
>
> m
Hi,
What are people's thoughts on requiring software to be compiled with
StackGuard?
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis
relies
upon (required packages), isn't available to be put in main, then it
should be a very obvious decision as to where the package that relies on
them should go.
Of course, when the situation changes, THEN you can move it into main --
but why should it be
ne).
>
> Thanks.
>
> manoj
>
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
I second the proposal made by Balazs Scheidler <[EMAIL PROTECTED]> on this
subject.
---
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410) 602-1350
Project Genesis
t.d/ directory
>
> Exactly.
>
> Which means we're trusting the value of IFS to be sane.
Forgive my ignorance, what is IFS used for?
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410)358-9800
Project Genesis http://www.torah.org/
the root
user. /etc/environment just doesn't exist
> [For example, take a look at how many scripts set IFS.]
Could you give me an example of one please? I couldn't find any in my
/etc/init.d/ directory
--
Brock Rozen [EMAIL PROTECTED
n vaguely useful as it stands. It *needs* to be followed
> by a "This can be achieved in the following manner...".
OK. What do we include?
This can be achieved in the following manner:
TZ=UTC
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
--
Brock Rozen
How about this, first incarnation mentioned by AJ:
Scripts must not assume the environment is at all sensible, and should do
something to ensure that the environment that they need is present.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical
priviledges.
Fine -- and what are the security implications here? Or are you just
saying, "I'm not sure there are any, but keep it in mind and try to find
them." ??
Thanks,
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410)358-9800
Project Genesis http://www.torah.org/
bably be stuck going back and forth on this, because I
> disagree with the fundamental philosophy (as I outlined in my previous
> message, and upon which you chose not to comment). Short version: the
I'm looking at the practical application and
o desire) then that's one
thing. OTOH, it's not only a matter of root's PATH being changed like
everyone is making it out to be. The above su command is a good example of
another case where the proper PATH might not be available unless the
script appends what it needs.
--
Brock
ating it by environment variable and not hard-coding what the
parent path is but refering to it by it's environment name.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410)358-9800
Project Genesis http://www.torah.org/
lved by using a ~/.ssh/environment file on
the target machine, but I happent o think that a wider solution is
necessary than just env, because just running a script doesn't
automatically tell you what PATH (or other variables) you need, which you
need to kno
; solution only solves it for a limited number at
any given time.
I'm not sure what the best solution is -- I like your proposal above that
I quoted. Essentially, the script owner needs to think through whatever
environment it needs and try and make sure it has a reasonable one. It
it inherits. It inherits what it inherits now anyhow -- so why should that
be any problem (it's certainly not a change) for this?
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410)358-9800
Projec
to have a very simple, standard setup (essentially exactly as
> init(8) sets things up). If it doesn't things break. That's life. [1]
Agreed -- but there's no reason not to insert another measely line into
all scripts to make sure that if somebody does play with that little area
tha
written however the maintainer wants them to be written. I think the time
for a policy has come, and that is should be (I'm biased) "append your
necessary PATH to the currently set path".
Below is the list of scripts that already overwrite PATH.
on for this).
If the PATH in the scripts is being APPENDED to the currently set PATH,
then I see no problem with #2 above -- which, you're correct, is the most
important consideration of the two.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410)358-9800
Project Genesis http://www.torah.org/
his -- but I wasn't asking for help in my
particular problem, and this doesn't work for rsh.
I still think the policy, modified a bit to make the PATH statement
appending rather than overriding is a good thing to have.
--
Brock Rozen [E
So then that should be the policy, that each script should append the PATH
it needs. Thus, we hurt noone, help the scripts and anybody else who has
played around with their PATH.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410)358-9800
Project Genesis http://www.torah.org/
e assumed that any programs run are in the PATH, as that
may be changed w/o connection to the script and then it would break the
script.
--
Brock Rozen [EMAIL PROTECTED]
Director of Technical Services (410)358-9800
Project Genesis http://www.torah.org/
64 matches
Mail list logo
