If you want to use rpath then you might want to check it with
somebody with experience in security (Debian security team?),
I think one of the arguments was about security. I may be
totally off here, but IIRC rpath also checks an environment
variable and this is considered very insecure.
HTH
t.aa
If you want to use rpath then you might want to check it with
somebody with experience in security (Debian security team?),
I think one of the arguments was about security. I may be
totally off here, but IIRC rpath also checks an environment
variable and this is considered very insecure.
HTH
t.a
I believe some similar cases have been handled earlier by
suggests type dependencies. The reasoning is:
- the main functionality does not require wish, so it must
not be required
- recommends is also a bit heavy handed for this, the
package is perfectly usable without it (i.e. no
functionalit
I believe some similar cases have been handled earlier by
suggests type dependencies. The reasoning is:
- the main functionality does not require wish, so it must
not be required
- recommends is also a bit heavy handed for this, the
package is perfectly usable without it (i.e. no
functionali
Hey Christian,
this guy is doing you a *favor*, and you are being rude to him.
If the bug is upstream, then it should be easy for you to know
if you have corrected it when you packaged the stuff. Then you
can close the bug with explanation: corrected in patch xx, which
was forwarded upstream 2000
Hey Christian,
this guy is doing you a *favor*, and you are being rude to him.
If the bug is upstream, then it should be easy for you to know
if you have corrected it when you packaged the stuff. Then you
can close the bug with explanation: corrected in patch xx, which
was forwarded upstream 200
For licensing issues you probably should use -legal
instead of -mentors.
Technically it is a modification to package it for
Debian. Do you think you have permission to:
- produce one shot package for Debian
- package this release for Debian *and* maintain the
packaging part in the future
- packa
The package in question was curl.
Root of this discussion:
http://www.debian.org/Lists-Archives/debian-mentors-9908/msg00059.html
the messages supporting my opinion:
http://www.debian.org/Lists-Archives/debian-mentors-9908/msg00074.html
http://www.debian.org/Lists-Archives/debian-mentors-9908/m
If you know, or suspect, that some might not do then make
that knowledge explicit (at least by not listing all similar
packages). All the packages providing *tags are probably
pretty equivalent, but yacc, byacc, bison etc. have differences
that mean that some grammars are not acceptable to all of t
iirc this exact situation was discussed rather recently with
some other package, and the result was that there is one /main
source archive. The division to '/us' and /non-us is not
important, especially now when apt can hide it from the user.
This would imply one source in /non-us and two binaries
The original bug report says:
Since `dhcpcd' is executed at startup
(in /etc/init.d/dhcpcd or /etc/init.d/networking) before
/etc/init.d/bootmisc.sh, these files are removed
during bootmisc.sh.
So the problem is that perfectly valid startup of dhcpcd
is later screwed up by bootmisc.sh which
/usr/share may not be even if /usr/sbin is, since it is
meant for stuff that can be shared for multiple machines
over network and can be mounted from another machine.
Is portsentry run before or after mounting network mounts?
Is it security critical and should work even if network
mount fails?
t.
All this comes out of thin air, but here goes:
* I think that currently the goal is to support the highest
optimization that does not hurt (noticeably) the low end
machines. I think this includes Pentium optimizations,
but naturally none of the instruction set extensions.
Optimization
Hi,
I think you are requested to give return type of
the function that implements the operator +=
e.g.
void operator+=(const FGString& other);
and no, upstream orphaning is not a requirement
to orphan it in Debian.
t.aa
Christian T. Steigies <[EMAIL PROTECTED]> Wed Sept 29, 1999 12:28 PM
>
There are many schools of thought on handling bugs like
these in Debian. There even has been some bug wars of
closing and reopening the same bug repeatedly, because of
these differences. So, there is no right answer, everybody
just Does The Right Thing and hopes it will be accepted.
That said, whe
When non-US was divided into non-US/main etc. it was
decreed, that /main & non-US/main together are the free
part, as determined by license. Placement into /main or
non-US/main is determined by export control laws which
have no bearing on licenses. So it is perfectly permissible
to have in /main a
Christian T. Steigies <[EMAIL PROTECTED]>
On: Thursday, July 08, 1999 12:04 PM
> [...]
> The source contains a gif image, do I have to remove that or
> ask the author
> to convert it to something "better"? The image itself is not
> needed, its just ... there.
GIF format is not restricted, nor re
Joey Hess <[EMAIL PROTECTED]> 30. June 1999 6:35
> [in response to Bradley Bell]
> There's nothing stopping you from using a different
> copyright. Many rules
> files do.
Yes but not all combinations of copyrights are compatible.
> (Which brings up a point - most debhelper rules files claim t
> From: Raul Miller [mailto:[EMAIL PROTECTED]
> Subject: Re: CDROM
> [...]
> [3] what Debian 2.0.2? [am I missing something? 2.0 is
> hamm, but what's
> 2.0.2? Something based on hamm-updates?]
correct verbiage for this is probably Debian 2.0r2
(r5 came out this year)
t.aa
Joey Hess wrote:
>
> Adam Di Carlo wrote:
> > This is irrelevant to you original question, but I really prefer to
> > use the POSIX 'command' command in order to determine whether an
> > executable exists on the path. I feel it is problematic to hard-code
> > paths into scripts, and any way to
Julian Gilbey wrote:
> [...]
> Erm, yes, forgot that bit!!
>
> You must check that you can do the following successfully, and that
> the package works after you have done each one:
>
> (a) Upgrade from the previous version and from the version in hamm.
> (b) Downgrade back again.
> (c) Install th
I don't know either. Did he mention any system where
matters are better? Had he any more specific comments?
Did he mean source packages or binary packages or both?
Here are some guesses, however:
- the (source) package does not document the required
environment to make package building repeatab
sgb-doc sounds like a *good* idea
t.aa
Julian Gilbey wrote:
> Julian:
> > aa:
> > > My 'crucial questions' would be:
> > > - is the amount of documentation (prose) significantly larger
> > > than
> > >that of code (apparently, otherwise there would not be the
> > > book)
> >
> > Compiled code
Adam Di Carlo wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Julian Gilbey) writes:
> >[Me]
> >> Hmm. Interesting. So how do you use it? You *extend* the library?
> >> Or you just read about it? ;)
>
> > [...] (In fact, it's so readable that it's
> > been published as a book.
Adam P. Harris writes:>
> Charles Briscoe-Smith <[EMAIL PROTECTED]> writes:
>[...]
> > # I've attempted to document all the cases as best I can. What's more,
> > # I even have reason to believe this script works! It does nothing,
> > # but if you replace the lines with a `:' at the left margin
Roderick:>
> [...]
> its own purpose. I'll have to rename my configuration file.
> [...]
> Are there cases I should be handling which this ignores?
downgrades
t.aa
Sascha:>
> Hi all,
>
> I've got a question regarding to majordomo which I am right packaging.
> majordomo got Debian-allocated uid and gid, is it necessary for postinst to
If you depend on the right version of base-passwd you can be *fairly*
sure that majordomo exists with right uid and gid
> c
David Goodwin:>
> On Tue, 27 Jan 1998 11:29:25 +0100 "Nathan L. Cutler" ([EMAIL PROTECTED])
> wrote:
>
> >Once there's a lower-volume alternative to debian-user (last time I checked
> >it was producing well over 100 messages a day), I'll subscribe to it. I
> >apologize for sending inappropriate
28 matches
Mail list logo
