f kludgingly using qmail features or
certain general smtp options, the administration should really be the
responsibility of the Debian Project Secretary (who might in turn delegate
the practical work to another volunteer.) This way, there is much less
chance of a group responsible going AWOL and not properly passing on his
tasks to a successor.
Also, a fully generic address doesn't have the potential "history"
problems that an address containing real person references.
Cheers,
Joost
the project secretary (or his delegate for maintainer maintenance) can
easily reset the main maintainer [subscription] address and best of all,
there will be no history problems, as [EMAIL PROTECTED] will always point to
the current maintainer of package "foo."
Cheers,
Joost
be maintained by (a delegate of) the
Project Secretary.
Since the topic has been brought up anyway, what about the following
alias: [EMAIL PROTECTED]
Heck no, even make it a package: [EMAIL PROTECTED] could
have a list too :-) (actually makes sense.) And bugs could be submitted
against it (makes sense too IHMO.)
Cheers,
Joost
st. That was
> when foo changes all who depend on it will be aware. That would be
> absolutely supreme.
Indeed a fine idea. AOL
Cheers,
Joost
too.
> PS: This is Qmail centric so should probably not be used if we ever
> want to switch to another MTA.
Some might consider that another reason indeed.
Cheers,
Joost
stay
informed and subscribe to [EMAIL PROTECTED] The same for
the new-maintainer people (or possibly the other way around.)
If I get my way, I'll volunteer for the maintainers maintainer work ;-)
Cheers,
Joost
Hi there,
I've just released menu-2.0. It has many new features, one of
wich is the automatic optimization of the menu tree, using
something I've called "hints". This is what I want to start
discussion about with this message.
First, why:
On my system, there are only two
Je 1999/06/19(6)/13:06, Joey Hess montris sian geniecon skribante:
> joost witteveen wrote:
> > I've just released menu-2.0. It has many new features, one of
> > wich is the automatic optimization of the menu tree, using
> > something I've called "
Je 1999/06/19(6)/14:06, Chris Waters montris sian geniecon skribante:
> I'm also a little concerned about possible confusion for the
> individual users. As it is now, when I install a new package, and I
> can't find the menu entry in the first place I look, I just go check
> the /usr/lib/menu/pkg
Je 1999/06/19(6)/14:06, Joey Hess montris sian geniecon skribante:
[..]
> Well the alternative that has been brought up before is to make everything
> use a deeper tree (like Apps/Editors/Big/Emacsen), and have menu
> automatically collapse the tree to Apps/Editors on your system with 2 editors
Je 1999/06/20(0)/12:06, Joseph Carter montris sian geniecon skribante:
> On Sun, Jun 20, 1999 at 02:50:51PM -0300, Nicolás Lichtmaier wrote:
> > > Would it be possible to group menu items that would be together, just do
> > > not
> > > put them in the menu? So my menu would become:
> > >
> > > Ap
Je 1999/06/19(6)/23:06, Richard Braakman montris sian geniecon skribante:
> joost witteveen wrote:
> > forcetree
> > Apps/Sound
> > endforcetree
>
> Is it also possible to specify that a menu (such as Apps) must have only
> submenus? Mixed menus seem cluttered an
Je 1999/06/20(0)/13:06, Edward Betts montris sian geniecon skribante:
> On debian-policy, joost witteveen <[EMAIL PROTECTED]> wrote:
> > Hi there,
> >
> > I've just released menu-2.0. It has many new features, one of
> > wich is the automatic optimization
Je 1999/06/21(1)/12:06, Chris Waters montris sian geniecon skribante:
> Joey Hess <[EMAIL PROTECTED]> writes:
>
> > Wow! You've utterly bypassed the whole policy issue with a brilliant idea!
>
> Well, no (though that was my first reaction too). We still should
> have a policy regarding the *defa
Je 1999/06/27(0)/15:06, Steve Greenland montris sian geniecon skribante:
> Consider that things like xdvi and tkman should be under "Apps/Viewers".
> It would never occur to me that they could be under "Apps/Multimedia";
> If I found them there, I would submit a bug to the package maintainers
> (w
Let me reply once more to this email, as either I don't
understand what is meant with `collapsing trees', or a lot
of other people don't.
Fearing about stuff originally placed in Apps/Vieuwers and Apps/Sound
suddenly being placed in Apps/MultiMedia, Steve wrote:
> I still don't think that I like
Saluton, Hello, Jó napot!
The debian menus currently currently only exist in
english, "en da's niet goed" (that's not good, Ott nem jó,
Tio malbonas).
Below I describe how I propose to change this.
At the end of this message I briefly discuss the gnome/kde
approach, and why I really like to make
Je 1999/07/02(5)/19:07, Steve Greenland montris sian geniecon skribante:
> [talking about Apps/Editors/Emacsen/..., and continuing about
> the collapsing trees:]
>
> Now consider the GIMP: its menu entry might be
> "Apps/Graphics/Editors/bitmaps". But even if the only installed package
> with a men
OK, install menu_2.1.0-2, type
LC_ALL=eo update-menus
and you will not anymore be able to understand the menus:)
(They will be in Esperanto, the only language available right now).
But before I start to call on translators to translate
messages/menu-messages.pot, there should be a better menu-
Je 1999/07/06(2)/13:07, Marco d'Itri montris sian geniecon skribante:
> On Jul 06, joost witteveen <[EMAIL PROTECTED]> wrote:
>
> >But for now, I hope you like the progress being made so far.
> I don't. You haven't replied to my concerns.
I'm very sorr
s more
> hierarchical and add subsections.
>
> However with the new menu-system as introduced by Joost I was wondering
> if we could use his dynamic menu system for packages as well? We could
> use our existing sections, perhaps add a second hierarchy level and use
> keywords in the same
yle.
I'm sure you are more eager than I am to spout further ideas about this.
Cheers,
Joost
ry nice at first glance. On second thought, I wonder if
"Debian Policy List Members" is an entity that you can legally assign a
copyright to. Will the copyright be enforcable? Does it still make any
sense to have such a copyright notice if not?
Perhaps you should consult debian-legal and maybe debian-policy too.
Cheers,
Joost
pts! (and you did not even include /var/lib/dpkg/info in the search.)
Maybe it would not be so unreasonable after all for Debian to become more
strict in the adaptation of POSIX definitions.
Cheers,
Joost
s as of the new policy, since dselect seems to make not much
> difference between these two relations.)
Then, I assume Ray suggests this:
Depends: gs
Suggests: gs-aladdin (>= 3.51) | gs (>= 3.51)
Is it now OK?
I mean, the package apparently is usefull with just gs-3.33.
So cannot it go in main?
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
o, the security hole wasn't all that big, as all that was possible
was denial of service attacs: most systems don't have /lib/modules
world-writable, so users cannot add that "setuid wrapper module"
mentioned, and thus cannot insert it at will.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
don't think so.
[1] Many of the .gz files (for example the executable ones) have to
be unzipped before being usefull. So, your comment applies equally
well to the .gz files. Even more so, as with gzip you have
to specify extra options to unzip the file to a different dir.
(gunzip
> joost witteveen wrote:
> >
> > Then don't untar them in place!
>
>
> I don't think that tarring files under /usr/doc/ is a good
> thing to do.
So you agree with me then, that you never are likely to run into
the problem you mentioned (dpkg not
ideal.
So, I have to put those files in /usr/doc/examples.
Of cource you can still argue that I should have untarred the
.tar.gz in /usr/doc/nfsroot/examples myself (in the debian/rules binary).
I argue that this will only create more subdirs, more mess.
and I would like to be allowed to give th
sroot: they'll have to become "unix-aware" first
anyway.
And yes, I realise you were talking about real documentation in
/usr/doc/*/*.tar.gz. Now, that's something different, and maybe
the maintainers should think again about those tarfiles. But
on the bases of those "doc.tar.gz" files you wanted policy to be changed
to the effect of not allowing .tar.gz in /usr/doc. That I think is wrong.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
e" files (not only docs, but also
> code example and config examples) referenced inside html docs as links
> to the file, not to the tarball.
Sure.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
hen, I don't know his/her opinion on those example files,
maybe he's got a good reason to put them together in a .tar.gz
file.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
em admin to re-link all those statically linked daemons,
and I'm sure some will be overlooked quite easily.
> Of course, that means that sites that want that kind of security will have
> to compile the daemons themselves.
And re-compile.
--
joost witteveen, [EMAIL PROTECTED]
#!/usr
bugreport
if he wanted to take over the package, but he declined. Should I then
just say "sorry, I'm not allowed to forward your patch upstream"?
Yes, I think in general we (debian maintainers) should do as much work
as possible. But I think it should be possible to discuss things
nues his benign dictatorship in the
very fine manner that he has been doing it ( Yes Dave, I realize that I am
braindead ) without any formalized enforcement that neither he nor Debian
needs as far as I can see.
Cheers,
Joost
On 24 Oct 1997, Manoj Srivastava wrote:
> Joost> The last time there was an issue, I actually enjoyed the fun to
> Joost> read digests and I frankly cannot imagine a situation where
> Joost> stronger action is needed ( except maybe for people posting
> Joost> their ker
nclude binary files.
But I rather like it that debian-source makes it more difficult to
include binary files, and don't even mind that the maintainer
has to resort to uuencode to include them: it should only be used
as a last resort.
--
joost witteveen, [EMAIL PROTECTED]
My spamfilte
a new maintainer every week, but
I would like to be able to know all formal procedures the new
maintainers have to go through. Is there a way to look at the
stuff new maintainers have to fill in or read? If not, do others
agree there should be one?
(Tempted to become a new maintainer, just to see w
On 13 Dec 1997, Ole [iso-8859-1] Jørgen Tetlie wrote:
> Joost Kooij <[EMAIL PROTECTED]> writes:
>
> > On 11 Dec 1997, Joey Hess wrote:
> >
> > > Package: rocks-n-diamonds
> > > Version: 0.9b-1
> > >
> > > rocksndiamonds: c
On 17 Dec 1997, Guy Maor wrote:
> Joost Kooij <[EMAIL PROTECTED]> writes:
>
> > How about adding a group "gamesadmin" to the system and making all level
> > definitions etc. owned by this group.
>
> Sounds like overkill to me.
>
> I think you sh
f people fid that all this information would require too much storage
space, then settings in /etc/dpkg/dpkg.conf could keep dpkg from storing
the data. BTW, if space is so much a concern, then a similar switch ala
"write-in-/usr/doc" would do nicely in /etc/dpkg/dpkg.conf.
Cheers,
Joost
Guy Maor wrote:
> Joost Kooij <[EMAIL PROTECTED]> writes:
>
> > That doesn't seem "simple" to me. It requires that a lot of games be
> > patched to allow for a command-line switch to override the location of
> > data files.
>
> I doubt t
possible generate a bash script that shows the doc pages with less.
(just to mention one possibility)
Personally, what I see that doc-base needs to do is convert the various
documentation formats into each other, that is something that is badly
needed. It may also provide a way to show wh
documents go in a nested structure, etc, and the final look of the
www page that contains all pages can very easily be modified.
What adds dhelp that dwww/menu doesn't already have?
--
joost witteveen, [EMAIL PROTECTED]
Potentially offensive files, part 5: /dev/random.
`head -c 4 /dev/random` may print 4-letter words (once every approx 4e8 tries).
add
this library.
[1] I had some g++/STL variables in my code, that gdb refused to show
the contents of, unless I gave it libraries with debugging info.
However, later I couldn't reproduce this anymore (I was using
different types, though).
--
joost witteveen, [EMAIL PROTECTE
1', `96-12-24', and starting with the year
> > 2000 `2000-12-24'.
>
> I'd say it should at least be optional to use 4 digit years instead.
I'd say that if the maintainer changes the upstream date anyway, a
4-digit year should be compulsory. (and at the very
> On 14 Jan, joost witteveen wrote:
> >>
> >> Debian Policy Weekly issue #5 :
> >>
> >>runtime pkg:shared lib stripped with --strip-unneeded
> >>develop pkg:static lib stripped with --strip-debug
> >>debu
e system.
Probably you don't realise that I don't disturb anyone on the system?
Please tell me (using runtime measurements or otherwise) how I distrub
anyone on the system by forcing the debugging libs on them?
--
joost witteveen, [EMAIL PROTECTED]
Potentially offensive files, part 5: /dev/random.
`head -c 4 /dev/random` may print 4-letter words (once every approx 4e8 tries).
x27;m more-or-less certain gdb simply reloads the libs in memory with mmap.
Thus they will only be in memory once.
> Anyway, you have not finished to comment on my proposal: what about
> having the source?
I'd like that, althought that would require all libraries to be
re-build again.
d release a newer
version of netbase. Maybe the netbase maintainer should be asked about his
recollections/opinion regards these matters.
> If this should be discussed in debian-policy please forward it
> there.
I think it makes sense to start a topic here, yes (besides, people are
getting rather emotional about the amount and nature of traffic on
debian-devel.)
Cheers,
Joost
.
Ideally, having something like menu, but for "dotfiles", allowing
maintenance scripts to write to parts of the configuration while keeping
user preferences and overrides, would make the case clearer, but I guess
in the absence of such a system, that is not really opportune now.
Cheers,
Joost
, group name, size in bytes, and timestamp (the
modification time unless other times are selected).
For files with a time that is more than 6 months
old or more than 1 hour into the future, the times
tamp contains the year instead of t
n-bugs, even if this doesn't
seem to happen very regularly at this moment.
IIRC I've even seen remarks from some maintainers that they don't keep bug
report mails and never look at the BTS.
Cheers,
Joost
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsub
53 matches
Mail list logo
