ted criteria anyway (or, at the very least, as many as Linux
does), I'm not sure why this thread is even still going. Either someone
cares enough to write (or adapt) the management tools and it gets included,
or they don't and it doesn't because nobody in their right m
On Thu, Mar 17, 2005 at 10:48:04PM +0100, David Schmitt wrote:
> On Thursday 17 March 2005 07:31, Joel Aelwyn wrote:
> > Don't even bother bringing up "redundant fiber". It may be, if it hasn't
> > been regroomed, and twenty plus years of network administrators
On Thu, Mar 17, 2005 at 07:14:27PM +0100, Marc Haber wrote:
> On Thu, 17 Mar 2005 10:03:15 -0700, Joel Aelwyn <[EMAIL PROTECTED]>
> wrote:
> >On Thu, Mar 17, 2005 at 01:09:33PM +0100, Marc Haber wrote:
> >> I am routinely running systems without any packet filtering cap
On Thu, Mar 17, 2005 at 01:09:33PM +0100, Marc Haber wrote:
> On Wed, 16 Mar 2005 20:39:48 -0700, Joel Aelwyn <[EMAIL PROTECTED]>
> wrote:
> >* The first rule of securing a machine exposed to the wilds is "Deny by
> > default, allow by need".
>
> Which is
[ Please respect the list code of conduct; I don't request CCs, nor does ]
[ my M-F-T get set as such. In other words, don't send them. ]
On Thu, Mar 17, 2005 at 12:16:27AM -0800, Thomas Bushnell BSG wrote:
> Joel Aelwyn <[EMAIL PROTECTED]> writes:
>
> &
On Wed, Mar 16, 2005 at 07:49:23PM -0800, Thomas Bushnell BSG wrote:
> Joel Aelwyn <[EMAIL PROTECTED]> writes:
>
> > If you really want this fixed, I suggest finding someone who is well versed
> > in both network security issues and Internet protocol fundamentals (not
>
On Wed, Mar 16, 2005 at 07:50:13PM -0800, Thomas Bushnell BSG wrote:
> Joel Aelwyn <[EMAIL PROTECTED]> writes:
>
> > * SCC systems have buildds.
> >
> > * Buildds must be network accessible.
> >
> > * The first rule of securing a machine exposed to the
]
[ The recommended setup, of course, would be for *all* buildds to be ]
[ sufficiently capable to handle the security queues, and for them]
[ all to then do so, whenever possible, but t
ir time (I hear money is often an excellent
motivator). The issues involved with writing a serious, production-capabl
e: entry. See the cdbs source package for some
useful things this can deal with.
Teac
ant to know (apart
from infrastructure) why it takes so long, try doing a package count.
Getting 10,000 *anything* to move together is a ch
parate "trusted buildd
admin" keyrin
elsewhere; just read
the debian-bsd a
oken. It is fairly
rare for the latter to get downgraded, simply because it usually indicates
a fairly major issue that may apply elsewhere as well, and if a maintainer
is awake and friendly enough to porting that it has been built in the first
place, they tend to be
hould be
closed for the moment, since I d
he more tightly integrated method of
dealing with this.
--
Joel Aelwyn &l
Can* it resolve that? I never did manage to sort
out whether the debconf policy stuff was merely "stro
t enough, or convince the DPL that this is a
large enough problem that it's leading to a non-functional team.
I would suggest reading the archives on -project, for last month, where
most of this has already been thoroughly discussed, but I
even
while obeying the letter.
Oh wait...
--
Joel Aelwyn
ible, I wouldn't rely on
> things like /proc/cmdline to be around come Li
On Thu, Mar 03, 2005 at 12:14:06PM -0800, Robert Carboneau wrote:
> Joel Aelwyn wrote:
> >It also looks like /proc/self/cmdline is more universal, if anyone did
> >need to do something of the sort.
>
> But that's just the process's command line, isn't it? I
e that
/proc/cmdline exists... (some systems really mean "proc" when they have
/proc mounted, if they have it mounted at all, not "random system
information").
It also looks like /proc/self/cmdline is more universal, if anyone did
need to do something
y and
> read-write branches, as well as insertion and deletion of branches
> anywhere in the fan-out.
All I have to say, having used union FS
On Tue, Mar 01, 2005 at 03:03:36AM +0100, Andreas Tille wrote:
> On Mon, 28 Feb 2005, Joel Aelwyn wrote:
>
> >I just make it a regular habit to scan my packages via the web interface,
> >if only to remind myself about the wishlist bugs sitting on some of them.
> Sure, that
this package.)
>
> I have no idea what causes it but the same thing happens to me a couple of
> times a year.
I just make it a regular habit to scan my packages via the web interface,
if only to remind myself about the wishlist bugs sitting on some of them.
Nothing's pe
On Wed, Feb 23, 2005 at 10:25:04PM +0100, Thiemo Seufer wrote:
> Joel Aelwyn wrote:
> [snip]
> > But that's OK. Our amd64 users just use the Alioth site instead of our
> > wonderful mirror network, and track it as unstable. I mean, it's so much
> > more effective
thoroughly half-assed
manner, but it's what some number of developers and users care about, s
#x27;, and
the fact that on most architectures, there *isn't* any way to specify
things short of a full-bore "all libc*-dev for all archs"
On Fri, Feb 18, 2005 at 09:17:55PM +, Henning Makholm wrote:
> Scripsit Joel Aelwyn <[EMAIL PROTECTED]>
>
> > The reason given in the origional thread was that these Depends are not
> > solely for building Debian packages (when Build-Essential is reasonable to
> &g
On Fri, Feb 18, 2005 at 06:50:50PM +0100, Kurt Roeckx wrote:
> On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote:
> >
> > *) The standard way of doing this today is to have a -dev package which
> > needs libc headers Depend on 'libc6-dev | libc-dev' to av
On Fri, Feb 18, 2005 at 06:30:42PM +0100, Bill Allombert wrote:
> On Thu, Feb 17, 2005 at 02:05:56PM -0700, Joel Aelwyn wrote:
> > So, while discussing a bug in a -dev with the maintainer, recently, it
> > reminded me to review an old thread from d-devel regarding the weird
> >
The reasons for it are long and not all that interesting unless you happen
to be interested in the field, and I'm too tired to go dig up a good
reference on Google, but I'm fairly sure one could be found without too
much difficulty.
Whether 'Y' or 'N
ges (those that use libc provided things like, oh,
stdio.h) do have a legitim
figure out a good, sane way to get fortune to grasp
the concept of supporting multiple languages *sanely* and in a way that
l
ith library search paths or don't permit the environment
to override it for security reasons).
I
aughter had this problem several times...
*looks innocent*
Say, whatever happened to debian-junior? Isn't that the sub-project that
was for exactly this sort of concern?
--
policy says "no exec bits", might
solve the issue of wanting to be able to use, say, ". confmodule" or the
like).
One can also do things like keeping a
e (say, off of the changes
list or out of the mail archive), and drop it into incoming along with
the files from the main archive; that should work just fine (modulo being
careful about signed changes files if you have 'require_sigs_meta' turned
on).
Speaking of which, it&
tly what the "libexec" directories are for. Which
would explain why the maintainer might thing there was no place for them,
as Debian does not currently support or use libexec...
However, barring that, I concur that /usr/share/ is probably the
right place, or
le and the examples given of
why there is an issue renders the assertion both non-obvious and without
rationale.
I stand in awe of your techniques. You're quite sure you won
e. Not just incidental, but "melt down your system
with processor load" levels.
Databases, for various reasons involving certain design patterns that work
well for them
On Wed, Jan 26, 2005 at 01:21:38PM -0600, John Hasler wrote:
> Joel Aelwyn writes:
> > Because policy, unlike RFCs, does not use normative declarations such as
> > SHOULD and MUST...
>
> >From debian-policy:
>In the normative part of this manual, the words must, s
tinely fail in
> prerm or postrm --remove, isn't that a release-critical bug?
Because policy, unlike RFCs, does not use normative declarations such as
SHOULD and MUST (note the reason for uppercasing them in RFCs - t
On Wed, Jan 26, 2005 at 10:30:01AM +, Andrew Suffield wrote:
> On Tue, Jan 25, 2005 at 06:01:26PM -0700, Joel Aelwyn wrote:
> > On Wed, Jan 26, 2005 at 12:06:06AM +, Andrew Suffield wrote:
> > > On Tue, Jan 25, 2005 at 10:52:48AM -0700, Joel Aelwyn wrote:
> > >
On Wed, Jan 26, 2005 at 12:06:06AM +, Andrew Suffield wrote:
> On Tue, Jan 25, 2005 at 10:52:48AM -0700, Joel Aelwyn wrote:
> > [1] Which is a separate rant, and frankly, I think Debian needs to be
> > clear about what we really mean by "We won't hide probles&qu
ke transparent process, especially when a process appears to
be hung or broken, and we don't seem to even be able to decide, amongst
ourselves, which we mean - perhaps because different camps want each to
be true. But I hesitate to even open the can of worms of "another Social
Contract
On Sat, Jan 22, 2005 at 12:53:43AM +0200, Lars Wirzenius wrote:
> pe, 2005-01-21 kello 15:42 -0700, Joel Aelwyn kirjoitti:
> > However, is it really unreasonable to expect someone willing and able to
> > build their own kernel to at *least* be able and willing to set up an
> >
me* source of NPTL (along with the script check
mentioned elsewhere).
Making it possible to install in a custom situa
programming on
LinuxThreads, or never used NPTL, or are unfamiliar with POSIX threads.
But, in one extremely short summary: "Too many to count".
As for MaxDB, I can't comment, except to say that programming for the
two is very different, and I doubt the upstream will care to support
Linu
ce
so many packages have a versioned dependancy on debhelper (in fact, just
about anything that has been set up to use it in the last release or two
probably is supposed to, according to teh docs.
nchez.net/~sanchezr/?page=debrepository
Another alternative is the 'debpool' package, currently available in
experimental. Yes, I wrote it, so of course I'm interested in it being
listed (though it might be useful, when writing a short description, to
check out the included 'RE
of the draw,
at least from outside the black box, as to what you get, for one notable
houldn't
cause any mor than a delay, and the other guy can still screw it up for
you.
O() notation is useful, but in the real world, one must always remember
tha
formed DEB package" - *not* "does
it meet the following policies" - could qualify as a CC, but frankly, the
term was never meant to be applied to such a beast, and I strongly suspect
th
54 matches
Mail list logo
