On Wed, Jun 07, 2006 at 02:04:18PM +1000, Anthony Towns wrote:
> On Tue, Jun 06, 2006 at 09:35:41PM -0500, John Goerzen wrote:
> > On Wed, Jun 07, 2006 at 12:02:16PM +1000, Anthony Towns wrote:
> > > > The ability to enter into a legal contract to indemnify a third party
&
On Wed, Jun 07, 2006 at 12:15:12PM -0500, Bill Allombert wrote:
> On Wed, Jun 07, 2006 at 09:46:57PM +1000, Anthony Towns wrote:
> > And hi to everyone from /.!
> > http://linux.slashdot.org/linux/06/06/07/047204.shtml for those playing
> > along
> > at home.
> If
On Wed, Jun 07, 2006 at 09:07:07AM -0500, John Goerzen wrote:
> So what am I trying to do?
> Most importantly, make sure that SPI and Debian aren't exposed to
> serious legal risks.
Then why don't you contact Greg and the SPI board yourself?
> As I've said already, I don't want SPI to be involved
On Wed, Jun 07, 2006 at 12:18:04PM +0100, Ian Jackson wrote:
> Jeremy Hankins writes ("Non-DD's in debian-legal"):
> > I'm not sure I understand this part, though. Do you think that folks
> > like myself, who are not DD's, should not participate in the discussions
> > on d-l?
> Actually, I think t
On Thu, Jun 08, 2006 at 02:47:24PM +1000, Anthony Towns wrote:
> On Wed, Jun 07, 2006 at 09:07:07AM -0500, John Goerzen wrote:
> > So what am I trying to do?
> > Most importantly, make sure that SPI and Debian aren't exposed to
> > serious legal risks.
> Then why don
On Thu, Jun 08, 2006 at 10:39:48PM +0300, Lars Wirzenius wrote:
> Fixing this would require having every increment of the jiffies counter
> to check for overflow, and using two counters. This is unnecessary
> overhead (a very small overhead, granted, but still), for a very small
> benefit.
No it w
On Mon, Jun 12, 2006 at 09:59:58PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > AFAIR, a package
> > should not have to depend on python2.3 and python2.4; instead, applications
> > that need a specific version of the interpreter should depend on it
> > themselv
On Tue, Jun 13, 2006 at 03:11:42PM -0700, Adam McKenna wrote:
> If people who aren't members are raising valid concerns that need to be
> addressed before development can proceed, we shouldn't reject that input on
> the basis of membership and call it "blocking development".
Right. But it's also p
Tim Connors wrote:
> only the occasional slowness as apt
> replaces libc6 and the /sbin/ldconfig program gets restored. I move it
> back out of the way when I notice that apt is taking so long, and all is
> fine.
man dpkg-divert
That should help with your libc6 upgrades.
--
To UNSUBSCRIBE, ema
Jonas Smedegaard wrote:
> (Include the long description here.)
>
Yes. Please do so.
Writing the long description in the ITP allows debian-devel to help spot
any mistakes in, and make suggestions for improvement to, the long
description.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a s
Bdale Garbee wrote:
>The following table summarizes pattern-matching default values:
>
>MembersDefault settings
>--
>Inclusion `--no-wildcards --anchored
>--no-w
Matthew Garrett wrote:
>
> Ok, but it still needs to be modified. Are you suggesting that the
> freedom to produce a binary that can't be recompiled by anyone else is a
> necessary freedom?
>
>
I haven't read the license, and I suggest asking on -legal if you want a
full analysis, but the gen
On Fri, Jun 30, 2006 at 05:38:31PM +0200, Steinar H. Gunderson wrote:
> On Fri, Jun 30, 2006 at 04:55:58PM +0200, Martin Schulze wrote:
> > You know that you can easily turn off this feature by adjusting apt.conf:
> Sure, and I've done so for several of my machines now. Actually, for many
> enough
Marco d'Itri wrote:
> Bullshit. The only criteria for defining freedom for the purposes of
> Debian *is* the DFSG.
Under a strict reading of the DFSG, I'm not sure how a license that
prohibits running the code would fail.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscr
Hi all,
At https://wiki.ubuntu.com/NoMoreSourcePackages is a description of
the new world order for Ubuntu packages -- which will simplify making
changes to Ubuntu packages to a matter of simply committing the change
to the source repository with bzr, and running a new command something
like "src
On Sun, Jul 16, 2006 at 10:12:37AM +0200, Goswin von Brederlow wrote:
> Will you setup the Debian DAK to allow source only uploads and apply
> patches to wanna-build and buildd for anyone willing to work on this?
No. All the above should be doable without needing any changes to any of
the project
On Sun, Jul 16, 2006 at 09:10:20AM +0200, martin f krafft wrote:
> also sprach Anthony Towns [2006.07.16.0847 +0200]:
> > At https://wiki.ubuntu.com/NoMoreSourcePackages is a description of
> > the new world order for Ubuntu packages -- which will simplify making
> > changes
On Sun, Jul 16, 2006 at 08:14:48PM +0200, Wouter Verhelst wrote:
> For starters, we'd need a *lot* of hardware to be able to do all these
> builds. Many of them will fail, because there *will* be people who will
> neglect to test their builds, and they will hog the machine so that
> other people (w
Wouter Verhelst wrote:
lemma A:
If people disagree, that's their problem.
lemma B:
In any case, I strongly disagree with the stance that the rudeness of a
particular developer would reflect on Debian as a whole.
lemma C: That's your problem
proof
from B have "You disagree" by simp
with A show ?
Charles Plessy wrote:
On Mon, Jan 10, 2005 at 07:14:29PM +0100, Wouter Verhelst wrote :
Why don't guys go to psychology class before telling people not to
be 'rude'?
Then what about keeping jokes for our private messages to our
friends ? Your suggestion to go back to classes is, to my stand
Thomas Bushnell BSG wrote:
Santiago Vila <[EMAIL PROTECTED]> writes:
I've created libofx0 and libofx1 which are the old and new versions,
and ask the ftp-masters to drop the old package entirely. I'll
request the other user of libofx to adapt accordingly.
Gar.
PLEASE DON'T INTRODUCE NEW PACKAGE NA
Thomas Bushnell BSG wrote:
Anthony Towns writes:
PLEASE DON'T INTRODUCE NEW PACKAGE NAMES GRATUITOUSLY.
So it seemed to me that because of my previous mistake it wasn't
gratuitous.
See the previous message for non-gratuitous reasons to change package
names. That wasn't one of the
Matt Zimmerman wrote:
On Mon, Jan 10, 2005 at 10:54:34PM +, Steve McIntyre wrote:
FWIW, our experiences with Ubuntu shows that having fast dinstall
cycles is very helpful. [...] It's a variant of the ïrelease often,
release earlyï principle.
(Strictly, it's an instance of the principle)
The dow
Frank Küster wrote:
Do I understand right that you recommend not to use libfoo1-dev,
libfoo2-dev generally, but that the most recent version should be just
libfoo-dev? The Debian library packaging guide gives the opposite
advice, to use libfoo-dev always, but I have learned that this
document does
Andreas Barth wrote:
with ideas and code (and a lot more) from Anthony, I was able to put
together the server part for partial patches in a way that it seems to
me that it might be included in dak. The resulting files are available
from
deb http://merkel.debian.org/~aba/debian sid main contrib
Henning Makholm wrote:
Scripsit Jens Peter Secher <[EMAIL PROTECTED]>
But the advice in the library packaging guide is to do something like
Package: libpackage2-dev
Provides: libpackage-dev
Conflicts: libpackage-dev
If the source-level API differs, then having libpackage2-de
Scott James Remnant wrote:
The stats:
8,920 source packages in Debian unstable main.
8,254 declare a build-dependency on debhelper
= 92% of packages build-depend on debhelper.
Is that sufficient to declare it build-essential?
Also of interest is that some 1300 packages would no longer need
Andreas Barth wrote:
* Hamish Moffatt ([EMAIL PROTECTED]) [050114 00:45]:
On Thu, Jan 13, 2005 at 02:26:52PM +0100, Steinar H. Gunderson wrote:
On Thu, Jan 13, 2005 at 11:19:03PM +1000, Anthony Towns wrote:
Also of interest is that some 1300 packages would no longer need to
declare a Build
Anthony Towns wrote:
Scott James Remnant wrote:
The stats:
8,920 source packages in Debian unstable main.
8,254 declare a build-dependency on debhelper
= 92% of packages build-depend on debhelper.
Is that sufficient to declare it build-essential?
Also of interest is that some 1300 packages
Frank Küster wrote:
Scott James Remnant <[EMAIL PROTECTED]> wrote:
In effect, if you're building unstable packages on stable, the first
thing you should build is unstable's build-essential.
Are you kidding? Well, this is okay if we're talking only about added
packages or higher versioned depends. B
Marco d'Itri wrote:
I see no reason to complain.
*Woah*.
Cheers,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> I'll dare to take the other route and ask: what is now holding back
> software such as mplayer/mencoder, transcode and mjpegtools from
> entering Debian?
Last time mplayer came up on debian-legal (the proper place for
questions like this), the problem was unclear licensing.
If the unclear lic
Goswin von Brederlow wrote:
Anthony Towns writes:
http://lintian.debian.org/reports/Tpackage-lacks-versioned-build-depends-on-debhelper.html
Having the current debhelper be build-essential would fix the ~237
bugs lintian finds for build-deps on debhelper that should be
versioned, but aren
Peter Samuelson wrote:
[Ken Bloom]
I'm confused. One making backports from sid to woody should backport
a package in such a way that it is buildable with woody's
build-essential.
AFAICS, that's no more true for build-essential than for anything else.
That is, you can either backport it so it build
Jay Berkenbilt wrote:
The recent threads on sonames and package names convinced me beyond a
doubt that I made a mistake in the names of the vips packages.
Oh dear...
[...] Right now, the vips7.10 source package creates four binary
packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and
libvi
Travis Crump wrote:
Should changelogs be in chronological order or should they be in version
number order?
The changelog should be in the order changes were made.
Specifically I just noticed that libtiff4's changelog is
out of chronological order[attached for reference]. It seems that the
main
Matthew Dempsky wrote:
Anthony Towns writes:
Travis Crump wrote:
Should changelogs be in chronological order or should they be in
version number order?
The changelog should be in the order changes were made.
Isn't that necessarily chronological order?
Not if you're merging two bra
Santiago Vila wrote:
On Mon, 17 Jan 2005, Anthony Towns wrote:
Each package Conflicts with the package it
replaces with a version << the future dummy transition version of the
existing packages and Replaces the old package as well. For example:
I'm fairly sure the above should ensur
Jay Berkenbilt wrote:
One reason for
putting the entries in version number order rather than in
chronological order was so that debuild -v3.6.1-5 would close all the
bugs tagged fixed-in-experimental from 3.7.0-1 and 3.7.0-2. To be
honest, I didn't investigate whether the right thing would have
ha
ation files :
modeless.ti TERMINFO version
modeless.tc TERMCAP version
Install the desired version that corresponds with your system.
Anthony
update95.shar
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpa
re's a different preinst in one of the bug reports, ummm, #34717 I think,
that does the diversion stuff itself, too.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The
e,
it's about either increasing choice (so you can install daemons even
if you don't want to run them for whatever reason), or about giving you
more knowledge about what's going on (so that when you install linuxconf
you find out that it comes with a remote configuration thingo
&1; then
]update-inetd --disable telnet
] fi
It might be better to bracket this with an `if [ "$1" != "upgrade" ]', or
similar. Herbert, does that sound right?
ssh strikes me as much better thing to use for remote updates, though :)
Cheers,
aj
--
Anthony Tow
original problem
pretty well, it seems to me.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. I
On Sun, Oct 03, 1999 at 09:44:25AM -0400, Raul Miller wrote:
> On Sat, Oct 02, 1999 at 12:30:04PM +1000, Anthony Towns wrote:
> > Just having /bin/sh included in the .deb is Good Enough -- diversions
> > work as designed.
> Good Enough is not good enough (TM).
*shrug* Name a c
On Sun, Oct 03, 1999 at 11:28:31AM -0400, Raul Miller wrote:
> On Sun, Oct 03, 1999 at 11:55:54PM +1000, Anthony Towns wrote:
> > *shrug* Name a case where it fails.
> You don't remember the problems when libreadline broke?
Yes, I do. That's not related to bash, it
On Sun, Oct 03, 1999 at 07:09:14PM -0400, Raul Miller wrote:
> On Mon, Oct 04, 1999 at 02:10:45AM +1000, Anthony Towns wrote:
> > (What is the problem with --rename, btw? I'm curious, and dpkg-divert is
> > horribly underdocumented)
> >From dpkg-divert --help:
> -
out better than I expected. The only two that I
deleted were contrib/ programs depending on pine/qmail/other things, all
the rest seem to actually be uninstallable.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save mys
files to describe
runlevels instead of directories and symlinks).
Cheers,
aj, who'd love to see a proper way of doing that
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is:
mething like
perl-5.004-base with a priority of 5004
perl-5.005-base with a priority of 5005
perl-5.004 with a priority of 15004
perl-5.005 with a priority of 15005
? Can this even be done, though?
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> &
x27;, then that's eir decision. They
could just as easily symlink /usr/bin/perl to a shell script that echoes
`PeRL SuX!!!11!!' and dies if they wanted to.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone sa
Santiago Vila wrote:
On Sun, 30 Jan 2005, Matthew Palmer wrote:
"Because I don't wanna play by the rules!" is not a rationale.
You are mistaken. I want to play by the rules, but the rules say
executables should go to /usr/bin, *not* that everything in /usr/bin
should be executable.
It also says tha
Santiago Vila wrote:
On Sun, 30 Jan 2005, Jochen Voss wrote:
I suggest that you read the reply by the author. For the benefit of
those who don't have web browsers, I'll quote it here:
gettext.sh is meant to be sourced from shell scripts, using the "."
command. This command looks in $PATH, but n
On Wed, Mar 22, 2000 at 03:51:48PM +0100, Richard Braakman wrote:
> On Wed, Mar 22, 2000 at 12:50:19PM +0100, Wichert Akkerman wrote:
> > > Package: netbase (debian/main).
> > > Maintainer: Anthony Towns <[EMAIL PROTECTED]>
> > > 59282 netbase: portmap is kil
d needs a rewrite. It also needs to remain more or less
compatible. It also needs to end up being very tidy and flexible.
I'll end up working on this eventually, if no one else does, but if
someone else it first...
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.
On Sat, Mar 25, 2000 at 09:37:38AM +0100, Miros/law `Jubal' Baran wrote:
> 25.03.2000 pisze Anthony Towns (aj@azure.humbug.org.au):
> > [0] update-inetd needs a rewrite. It also needs to remain more or less
> > compatible. It also needs to end up being very tidy and flexib
7;t really seem a huge amount of choice here, to me.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's s
rm*ColorMode: no' seems like it'd do what you want.
> Please leave *personal* configuration to the *user*
Indeed.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
`
On Sun, Mar 26, 2000 at 04:02:20PM +0200, Marcus Brinkmann wrote:
> On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote:
> > The whole file --- verifying each entry would take at least three minutes
> > on my hardware, and god knows how long on anything moderately old or
On Mon, Mar 27, 2000 at 12:17:47PM +0200, Robert Bihlmeyer wrote:
> Anthony Towns writes:
> > The only reason not to trust a key dinstall uses explicitly for signing
> > Packages is if you believe dinstall is compromised. If you believe that,
> > then you shouldn't b
out any intervention,
as I understand it. Including ports. They're moved from Incoming to
unstable without interaction, but that's about it.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encr
#x27;t in potato or woody)
tkhylafax (not installable on any arch, depends on hylafax-client,
which isn't in potato)
tkirc (not installable on any arch, depends on ircii, which isn't in
potato or woody)
Cheers,
aj
--
Anthony Towns <[E
ically choose packages from there
when you tell it to do an apt-get dist-upgrade; it'll only use it for
packages you specifically select with apt-get install.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save mysel
loading to non-US/main.
That's my understanding anyway.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's s
On Tue, Mar 28, 2000 at 01:20:33PM +1000, Anthony Towns wrote:
> There's a list of uninstallable packages for both woody and potato
> (sorted by source package) linked from there too. Stats for potato at
> the moment are: (number of uninstallable binary packages by arch)
>
s
Packages files? Where, exactly, is the vulnerability that makes it so
obviously insecure?
And note this is not to say that we shouldn't /also/ have keys added
to the .deb's themselves, just that we can get most of the security
we might like --- certainly for all the com
sticking in a preinst and randomly
killing processes. It also depends on an optional package, which ain't
good.
Ideas? Or should I just forget it, and let people doing an upgrade look
out for themselves?
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj
*\):\([0-9]*\)
\([0-9]*\)/\(.*\)$,\3 \1 \4,p' |
sed -n "s/^$a $b //p";
done 2>/dev/null |
sort |
uniq |
xargs ps u
...seems to work.
Yeesh.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~a
. Maybe it'd be better to just keep
releasing once-a-year or so (with any extra security-fixes), and let
people who really want new packages upgrade to testing. As opposed to
making a release every three, four or six months, say.
And, of course, none of this solves our current problem, whi
ys trust baz,
though, which is my point above)
> However, even the simplest approach that is based on per-package-signing has
> a positive effect on package security (bumps it from currently zero to some
> positiv value), while the signed Package file gains nothing. (It would, but
> ON
On Sat, Apr 01, 2000 at 12:15:01PM +1000, Anthony Towns wrote:
(among many other minor typos)
> You can differentiated probably good but outdated old packages, and probably
^^
This should read "can't differentiate". Whoops.
> bad but outdated old
how I was toying with doing it a while ago, and
apart from not knowing how to make an Apt option, or wanting to do a
system call properly and elegantly (as opposed to using system()) it
was working fairly well.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.
On Fri, Mar 31, 2000 at 09:31:31PM -0700, Jason Gunthorpe wrote:
> On Sat, 1 Apr 2000, Anthony Towns wrote:
> > * the web of trust, and having the ftp-team sign it
> The average user has no entry to the web of trust, so this is just as
> useless. (and massively involved for ou
On Sat, Apr 01, 2000 at 04:00:20PM +0200, Marcus Brinkmann wrote:
> On Sat, Apr 01, 2000 at 12:55:53PM +1000, Anthony Towns wrote:
> > But unfortunately that's not quite the choice I have either, since for
> > some reason that I can't fathom, people seem to think that a
e
> their personal key in the latter case, I can trust it.
Are you really sure that no developer stores their key on a net connected
machine?
Also, what's so fundamentally wrong with transferring a secret key over
the net? Hint: PGP does it every time you send an encrypted email.
Cheers
x27;s
the bit I was referring to) *sends that secret IDEA key across the net*.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVI
The rest can then be automated,
> just as dinstall is.
This is acceptable right now, but I remain confident that new-maintainer will
actually one day reopen. Having the debian-keyring not be automatically
updatable is horrible.
I /think/ under your model it can still be automatically update
On Sun, Apr 02, 2000 at 01:00:56PM +0200, Bart Schuller wrote:
> On Sun, Apr 02, 2000 at 02:46:30PM +1000, Anthony Towns wrote:
> > PGP (v2.x, I'm not uptodate with the recent OpenPGP stuff), generates a
> > secret (albeit symmetric, rather than public/private keypair) IDEA k
them. Often though, this is just as good.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results
r to compromise huge numbers of
Debian boxen.
I probably should add a rider that it's already quite difficult to do
this; developers machines aren't your regular `let's install RedHat
5.0 and leave all the default servers running', nor are most mirrors,
and certainly most popular
games/mygame --update-score-file-format
...with the malicious code in the game source itself seems pretty
clandestine.
Self-modifying postinsts are probably possible too, with some care.
Cheers,
aj, thinking like a criminal since 1978
--
Anthony Towns <[EMAIL PROTECTED]> <http://azu
ips is something different than what
> the maintainer put together, I shall neglect all responsibility for all my
> packages from now on.
I realise this is a pretty popular rhetorical technique these days,
but really...
Cheers,
aj
[0] If you really wanted to avoid this *without* changing dp
or Debian should serve all people, those who use apt, those who use dpkg
> and downloaded files, those who use other methods (dselect etc).
Is this satisfied too, now, then? Well, perhaps not satisfied, but at
least somewhat alleviated? (For people who download by hand and just
use dpkg, clearly dpkg
e for someone interested: hack ssh-agent so it pops up a window
which you can use to say `yes' or `no' to requests from non-localhosts for
secret key operations. Usual provisos about making this an option, and not
breaking things for people who don't use X, and so
Russell Coker wrote:
<[EMAIL PROTECTED]> wrote:
Ahh, it's the "I can deal with it therefore it's OK" line. What if
there is another solution? Are you even prepared to consider that
possibility?
That's not the issue. The issue is that there are many stressful situations
in life and adults have t
elds to a Packages file, something like:
$ cat tasks
networking netbase
metasyntactical-packages foo
$ ./add-task /var/lib/dpkg/available < tasks | less
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~
rnel-image-blah/make-a-boot-floppy no
fi
fi
should be used, I suppose. Or perhaps:
if debconf/interactive-postinst = yes; then
db_input kernel-image-blah/make-a-boot-floppy
else
db_input kernel-image-blah/cant-make-a-boot-flopp
gt; myself going super-user to issue the command rather than running
> /sbin/ifconfig.
ifconfig is a required file for /sbin according the the FHS section 3.10
as distributed in the debian-policy package.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~
On Tue, Aug 15, 2000 at 08:26:50PM -0700, Joey Hess wrote:
> Anthony Towns wrote:
> > Basically, I'd like to be able to insist that I'm *never* asked a question
> > as part of a postinst. I'd rather the postinst fail (and I'd rather Apt/Dpkg
> > ju
with cryptographic program code must be stored on the
- "non-us" server because of export restrictions of the U.S.
+ "non-US" server because of export restrictions of the U.S. Such
+ programs must be distributed in the appropriate non-US section,
+ either non-US
move
> these things around as LOCAL scripts may depend on them.
Similarly for /var/mail, /usr/lib/sendmail, /usr/doc, and so on, albeit
perhaps to a lesser extent.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone sav
gt; physical place is elsewhere. This does not violate the standard.
> This has nasty implications with the current implementation of dpkg,
> given that /sbin is currently a "real" directory on debian systems.
Are you sure? I believe this bug's been fixed in the dpkg in potato.
Cheer
sions, or check that various packages in base are all on CD#1, or
similar.
The more checking and testing we can offload from volunteers onto machines,
the better. We can always get more machines, getting more people with the
requisite clues and free time is much harder.
YMMV.
is, a new distribution is added between
> stable and unstable, that is regularly and automatically
> updated with new packages from unstable when they've
> had a little testing and now new RC bugs.
>
> (Anthony Towns; de
ou
probably want.
This latter method has the advantage that it just requires changes to
dpkg and apt and friends without also requiring every single package be
updated to support the new way of doing things.
It might turn out to be useful to let packages be slightly more specific
than
with tasks though, too.
The other way of doing it that springs to mind, might be:
Package: freecraft
Groups: priority-optional, task-games/networking, section-games
(if you *really* group everything into just one way of doing things),
but I think this would probably req
if you are
> trying to provoke a flamewar, I will conduct no further discorse with
> you. [...]
See what working on non-free software does to people?
*sniff*
It's sad.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak
p being mostly
self correcting. And even if it's not, we're still in a better situation
than we are now because some bugs *definitely* won't make it into testing.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.hu
table once released though.
And what's with the "unlike some people like you to believe" nonsence?
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject:
ly disappointing to have licensing problems
stoping Debian from distributing either of the main desktop environments.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject
401 - 500 of 1307 matches
Mail list logo