Je 1999/07/23(5)/23:07, Wichert Akkerman montris sian geniecon skribante:
[2K packages problem: more more sections, hierarchical sections, etc]
> There have been proposals of using keywords to make it easy to search
> for packages, and people suggesting that we make the sections more
> hierarchic
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
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/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
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
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
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
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/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/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)/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)/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/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)/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 "
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
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.
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).
> 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
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
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
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).
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
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
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
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
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
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/
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/
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/
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
> 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
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
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/
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/
34 matches
Mail list logo
