* Joey Hess [EMAIL PROTECTED] [000926 14:52]:
Nicolás Lichtmaier wrote:
Your point is so obvious. duh... how did I miss that?
Of course that cracking bin would be like cracking root...!
This is not an issue if
a) bin has no passowrd so people cannot log in as bin
and
b) nothing on
Greetings all;
For today's apt-get upgrade, I had to answer the ``replace conffile''
question many times for the kde2 packages' .*desktop files. I don't
recall changing any of the .desktop files, so it would have been nice if
it just replaced them all on their own. However, I think a setup
* Anthony Towns aj@azure.humbug.org.au [001009 21:10]:
Well, which of emacs or vi should be the preferred editor?
This is missing the biggest question of all -- which of the various Vi
clones should be THE vi Debian suggests?
Vim, of course.
:)
* Joey Hess [EMAIL PROTECTED] [001024 15:23]:
Policy explictly says you should NOT output things to stave off boredom
on the part of a user. Displaying stuff for tasks that may be slow on
my 386 clearly falls under that.
Hmm; I myself like twizzle sticks (ala fsck) to let one know the machine
* [EMAIL PROTECTED] [EMAIL PROTECTED] [001029 18:54]:
Maybe some upgrades should just be labelled reboot recommended?
It will be a sad day when this happens. :( I think it is a strong
selling point when I tell my MS friends, tired of rebooting after
installing a new web browser, that one can run
Greetings Daniele, [I have cc'd you, since I do not know if you are
subscribed to -policy]
* Daniele Cruciani [EMAIL PROTECTED] [001110 06:37]:
I think this is the right place for asking change on policy
about doc-base registering of package.
Sadly, I'm not sure what you are proposing
* Bernd Eckenfels [EMAIL PROTECTED] [001119 15:08]:
So dou u want to make the task-secure-system package conflict with
telnet-server? Since we also have secure telnet severs (telnetd-ssl). So the
problem is we want to make sure that task-secure-system also removes
insecure packages (at least
* Joey Hess [EMAIL PROTECTED] [001129 16:17]:
[...] sign a concacentation of their md5sums? [...]
I don't understand how signing a uuid that is just listed in the control
file and could be modified by anyone is cryptographically secure.
I would like to suggest that whatever signature scheme is
* Reimer, Fred [EMAIL PROTECTED] [001129 17:03]:
The easy answer to that is that the version should automatically get
bumped for user builds much like the kernel compile # is for Linux. The
maintainers, when generating an official version, can specify the exact
version when they compile the
* Rando Christensen [EMAIL PROTECTED] [001129 21:27]:
What I would most like to see myself is adding a /etc/licensing/
directory in which every license used on the system can esist, for
example:
/etc/licensing/
\-- GPL
\-- BSD
\-- Other
$ cd
* Brian Mays [EMAIL PROTECTED] [001130 19:41]:
If we're going to be so anal about interpreting the GPL, then why
doesn't anyone mention the requirements for distributing the source.
Actually... we have agreed to one of: accompany the programs with
complete source, the three-year offer, or ``the
Ok. I have discussed this a bit with my roommate, and we have a
suggestion:
Make the GPL show up in ftp motd and perhaps even the web server
(headers?) and mention that many packages, as indicated, are covered
under the GPL. We also mention that redistribution of the packages
requires giving the
* Thomas Bushnell, BSG [EMAIL PROTECTED] [001205 18:49]:
For all I know, you're Theo de Raadt, and you're deliberately trying
to drive a wedge between the FSF and Debian out of hatred for
everything GPL and everything that is not OpenBSD.
Naw, if you think Theo has that kind of time (or
* Thomas Bushnell, BSG [EMAIL PROTECTED] [001205 19:05]:
Oh, I agree it's not likely. But surely there are Theo wannabies
(horror) who do have the time.
I'm still in training.
:-
--
``Oh Lord; Ooh you are so big; So absolutely huge; Gosh we're all
really impressed down here, I can tell
* Raul Miller [EMAIL PROTECTED] [001205 20:37]:
Fortunately, things aren't very severe right now. And, certainly,
I think that if we could pull a solution together by the time that
Woody freezes, that would indicate good faith.
It might not hurt to wait for RMS to get back to us wrt what his
* Joey Hess [EMAIL PROTECTED] [001206 21:30]:
Task packages are packages whose names are prefixed with `task-'.
Typically they are empty metapackages that merely depend on a collection
of other packages.
Joey, nice work; I agree with the general gist of what you are aiming
for. When I
* John Galt [EMAIL PROTECTED] [001207 18:14]:
distributions is the right one. Uncle Debian in his wisdom makes the
choice for him and takes care of the details.
Fuck Uncle Debian and the horse he rode in on if that's the case.
Now John, I consider myself fairly competent; however, with
* Brian May [EMAIL PROTECTED] [010126 15:32]:
Please give me a real life example of why distinguishing libraries
solely by their major version number is not good enough...
How does this work with the glibc mess I seem to recall from about a
month ago?
--
``Oh Lord; Ooh you are so big; So
* Arthur Korn [EMAIL PROTECTED] [010128 03:48]:
Shure the US is getting preferential treatment. Would you ever
bother to set up master in, say, Iran and have to maintain a
second master even though everything could be put onto the
second master in the first place?
I would guess a large part
* Brian May [EMAIL PROTECTED] [010205 02:39]:
I disagree. Why should dpkg, for instance, which is specific to Debian
come with a diff format.
Ah, but dpkg isn't specific to Debian. It is licensed in such a fashion
that allows its use in other projects.
(Of course, anyone likely to use dpkg
IIRC, woody is the last name from toy story that we haven't used yet.
Does the Cabal know which movie (if any) is next? How about Chicken Run,
or the Wallace and Gromit series? Or MST3K? (Just consider, ``Manos,
Operating System of Fate!'' as a login banner. :)
(BTW, to join the Cabal, do I
D, while I don't want to reject the idea out of hand (noting that my
only affiliation with Debian is enjoying it on my own computers, and
spending far too much time helping people on the mail lists) I don't
see any reason for changing our current system.
Perhaps if you would point out the faults
* Anthony Towns aj@azure.humbug.org.au [010216 19:43]:
The easiest solution that I can think of (ie, that doesn't cause difficult
to detect breakage, and that doesn't involve further significant changes
or too much awkwardness) is, during the freeze, to just upload major
changes to
* Julian Gilbey [EMAIL PROTECTED] [010220 07:29]:
Good. How about something like cron.* scripts should not produce any
non-error output in general. An exception may be made if the
intention of the script is to mail a status report to root.
Why specifically root? I could imagine situations
* Arthur Korn [EMAIL PROTECTED] [010220 09:35]:
So what about:
cron.* scripts should not produce any non-error output in
general. An exception may be made if the intention of the
script is to mail a status report to the administrator.
I like this, though the should not use stdout
* Sean 'Shaleh' Perry [EMAIL PROTECTED] [010220 10:39]:
Anyone have comments on the idea that the only packages we should release are
ones that have a maintainer, not Debian QA?
In taking a quick list at the packages my machine knows about, it sure
appears that Debian could still be useful if
* Adrian Bunk [EMAIL PROTECTED] [010220 13:52]:
On Tue, 20 Feb 2001, Sean 'Shaleh' Perry wrote:
So, perhaps we should drop the bar a little. If your package is not at
least
3.x.x, it gets held.
And just out of curiosity: apt has standards version 2.4.1
That is interesting. Of course, I
* Brian May [EMAIL PROTECTED] [010305 22:20]:
I would suggest that it would be better use of the maintainers time
fixing problems.
It shouldn't be that tough; note whatever the --prefix etc options are
to the configure script if it has one, and make a note of this in
README.Debian. For those
* Anthony Towns aj@azure.humbug.org.au [010325 01:11]:
BTW, I'm inclined to think it'd be a good idea for people who want to add
a must requirement (or to change a should to a must) to include a list of
packages that would need to be removed from the distribution due to the
change. Anyone
* Anthony Towns aj@azure.humbug.org.au [010325 02:30]:
If you're not going to bother filing the RC bugs, there's no reason
not to leave it as a should. If you are going to file the RC bugs,
then someone's got to figure out which packages it applies to at some
point anyway.
This makes sense if
* Antti-Juhani Kaijanaho [EMAIL PROTECTED] [010402 01:32]:
On 20010402T030737-0500, Manoj Srivastava wrote:
So, what is the provenance of this CURDIR variable? Has it
been blessed by POSIX? indeed not.
I believe this is irrelevant, as portable make is next to useless.
I'll admit I
Frank, I understand Debian Policy's purpose is to document what Debian
considers good practice, not document the tools that may be used. Thus,
I think it is perfectly acceptable for Debian Policy to defer to the
update-menu documentation for the proper format of the menu files.
If this bug is
* Julian Gilbey [EMAIL PROTECTED] [010412 17:03]:
My suggestion is: change should to must in policy, and give
packages some time to migrate (eg., one year) before starting to do
NMUs. Then any packages uploaded within the coming year will have to
satisfy this requirement (or have a lintian
* Alexander Hvostov [EMAIL PROTECTED] [010412 22:47]:
I'd frankly prefer some sort of strong typing mechanism on the filesystem
(like in MacOS), but that wouldn't be altogether helpful here. Just a thought
I had when I read this...
jerk
Why don't you compile a list of the worst features of all
[I've gotten to the point of not knowing who said what.. so all
attributions are cut.]
Or better, it requires that the delivery agent runs under uid of the user
that owns the mailbox.
But then the delivery agent has to start off running as root to fire
off an MDA with the user id of
* Anthony Towns aj@azure.humbug.org.au [010416 05:54]:
Does that possibility satisfy everyone:
- MUST and SHOULD change to the universally-recognised IETF meanings
It's still not clear why this would be a Good Thing.
The only real reason I've seen is that it's confusing people (and then,
* Wichert Akkerman [EMAIL PROTECTED] [010426 11:18]:
Previously Daniel Kobras wrote:
For now I added a lintian overrides for this, but Sean asked me to bring up
discussion here to clarify what lintian should treat as shared lib in the
future in order to properly solve this issue.
Geez,
* Josip Rodin [EMAIL PROTECTED] [010426 14:54]:
Our inability to get this into Policy is appaling, isn't it? :
Especially since both you and Wichert have put effort into this -- that
is two possible seconds for a proposal. I've taken a closer look at the
policy-process text and I do not think I
Greetings; I am pleased that Josip's proposal has received several
seconds. (Though I don't think many were signed -- I am fairly certain
that they do need to be signed to count!)
Since my goal is to get this thing taken care of as easily as possible,
I am retracting both my policy proposals so
* Anthony Towns aj@azure.humbug.org.au [010506 00:05]:
Seconded, with the proviso that I reserve the right to later be
disagreeable about some of the musts...
AJ, I don't think anyone would ever expect you to give up being
disagreeable about musts. :) Actually, we might be rather
disappointed
* Sam TH [EMAIL PROTECTED] [010507 00:11]:
I've never seen AbiWord work over remote X if the fonts weren't
installed in *both* locations. Thus, AbiWord installs on a machine
without the fonts are *not useful* *at all*.
Sam, please don't take offense at this: the way I see it, if program
* Manoj Srivastava [EMAIL PROTECTED] [010507 13:53]:
field; and using the standards version field as a reason ti file bugs
is just plain wrong.
Is this working under the assumption that the release manager will drop
all packages not recent enough when freezing?
--
Earthlink: The #1 provider
* Julian Gilbey [EMAIL PROTECTED] [010507 15:44]:
Most init.d scripts are expected to support all of start, stop,
etc. options. But there are a small number of scripts which are
obvious exceptions to this rule: restart, reboot, single, mountall.sh
and so on.
Julian, I'm inclined to think
* Karl M. Hegbloom [EMAIL PROTECTED] [010512 20:24]:
Is this always true?
7.5.1 Overwriting files in other packages
Firstly, as mentioned before, it is usually an error for a package to
contain files which are on the system in another package, though
currently the --force-overwrite
44 matches
Mail list logo
