Russ Allbery wrote:
The one exception I can think of is if someone really wants to
customize the [spamassassin daily] job. That can be a little more
tedious to do with timer units. Right now, I think there's a bunch of
logic in the /etc/cron.daily script that someone could in theory
change. But
Phil Hands wrote:
I saw that at least one package (I'm afraid I've forgotten which)
settled on this picture of Grace Hooper:
https://upload.wikimedia.org/wikipedia/commons/a/ad/Commodore_Grace_M._Hopper%2C_USN_%28covered%29.jpg
It is Public Domain (having been released by the US Navy).
Russ Allbery r...@debian.org writes:
I keep being tempted to go off on a rant about how we have all of
these modern, sophisticated, much more expressive programming
languages, and yet still none of them handle ABI versioning as well as
C does. Normal versioning problems that we just take for
Steve Langasek wrote:
Matthew Woodcraft wrote:
Debian has supported booting from md RAID without using an initramfs for
a very long time.
True but misleading. LILO supported it because it hard-coded the block list
of the kernel and initrd at install time. GRUB1 never supported any RAID
Wouter Verhelst wrote:
Since you're talking of software RAID and LVM, that means you need an
initramfs to boot your system. Thus, your systems will continue to
boot with the proposed scenario, which supports booting with /usr on a
separate filesystem if you have an initramfs.
Using software
Russ Allbery wrote:
I think the core question is: why is base-files special? Yes, it's
essential and all, but that doesn't address the case of packages being
downloaded separate from Debian, or unpacked by hand, in which case we
don't include a license. If we're legally fine with that, I'm
Axel Beckert a...@debian.org wrote:
Simon McVittie wrote:
Would it be enough for the your old screen binary is
/tmp/screen-yhpoe8r/screen notice to also say if your /tmp is mounted
noexec, you might need to copy it elsewhere to run it?
That's my current plan -- with the noexec notice just
Adeodato wrote:
On the other hand, the bit about running `debian/rules build` by hand
seems valid to me.
Indeed, that's what my fingers are used to typing if I just want a
patched package for local use. I wouldn't be surprised if there were
lots of other users who are the same.
The various
Bastian Blank [EMAIL PROTECTED] wrote:
The manpage of tar does not mention the special handling of a
environment variable named TAPE. Nor does tar --help.
But, unsurprisingly, the tar manual does (under the --file option).
-M-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Joey Hess [EMAIL PROTECTED] wrote:
This thread has concentrated on fixing packages, but I would
appreciate a little insight into why someone might set TAPE in their
environment by default. Surely if you set it by default, you must
realse that you're asking any such invocation of tar to write
Marco d'Itri [EMAIL PROTECTED] wrote:
So, does anybody mind if I remove depmod from the module-init-tools init
script?
So I did it. Since yesterday depmod -A is not run at boot time anymore.
Will the case described in this message (from the postinst for kernel .debs
made by kernel-package)
Karl Chen [EMAIL PROTECTED] wrote:
Suppose package P contains files /usr/bin/B1 and /usr/bin/B2. B1
is the important program, and B2 is not as important. Is it OK
for the declared package dependencies to not satisfy all the
run-time shared library dependencies of B2? What if they are
listed in
Wouter Verhelst wrote:
* The Invariant Section is retained, but another Invariant Section
containing a rebuttal is added to the document. This would a) look
silly, and b) be a beginning of Invariant Section bloat, in which a
document could consist of 10% Invariant Sections, 60%
Wouter Verhelst wrote:
A more realistic example would be
Answer: Because the document contains an invariant section on the
author's opinion regarding the dangers of Software Patents in
the European Union.
Something like that simply is not free. It might be true at the time the
I am wondering if we aren't violating the spirit if not the letter of
LSB by using a non-standard version of install-info.
While of course the LSB says nothing about install-info, the fact that
Debian distributes a program under the name 'install-info' which is
incompatible with the GNU version
On Mon, Sep 02, 2002 at 11:19:26PM +0200, Josip Rodin wrote:
As it has been pointed out hundreds of times, it is GNU that distributes a
program under then name 'install-info' which is incompatible with the dpkg
version. :)
(The version in dpkg has seniority.)
It's not a matter of seniority,
On Mon, Sep 02, 2002 at 11:57:03PM +0200, Josip Rodin wrote:
Anyway, this discussion is superfluous too, as the dpkg maintainers have
already decided to move over to the C, GNU version in the future. (See
debian-dpkg list archives for details.)
I am pleased to hear this.
-M-
Ian Sharpe [EMAIL PROTECTED] wrote:
Is there a Debian-preferred location for .ali files (etc) produced by
the Gnat Ada compiler? The pattern seems to be:
.a/.so files in /usr/lib
.ali files in /usr/lib/xxx
.ads/.adb files in /usr/include/xxx
where xxx is the package that the library is a
[EMAIL PROTECTED] wrote:
I have a question: whydo we have to keep .adb files in the package
since .ads files are meant to contain the interface? (well, indeed
except from generics).
I don't know that we 'have to', but one reason to do so is that gnat can
inline subprograms across unit
19 matches
Mail list logo
