Re: auditd as logrotate replacement?

2001-04-25 Thread Arthur Korn
Sean 'Shaleh' Perry schrieb:
 as long as lograte can be installed first, then I can later
 install auditd and everything will just work, sure.

I can't use logrotate with msyslog, it won't work, logrotate is
just too limited. This would mean I have to move msyslog to
non-US, since I will make it depend on auditd.

So, basically, since auditd does feature encryption, it does not
have any chance to be the default for log rotation, even if it
was a lot better than logrotate? What giant pile of crap.

 Since it is in non-us, at least for now that means it will not
 appear on a official debian cd.

Did I say I hate it?

Shaleh, don't take it personally ...

ciao, 2ri
-- 
locate sunny|grep place|xargs cat|paste ~/me
sleep 4h




Re: NMUers: STOP BEING STUPID

2001-04-24 Thread Arthur Korn
Hi

Richard Braakman schrieb:
 In that case the right repository could be a bugreport to the package
 involved.  That way the diff submission is guaranteed.

I agree with you that _something_ has to be done about
catastrophal NMUs, but just stopping to NMU and only submitting
diffs, even on packages where it is clear that the maintainer
stopped working on them some years ago can't be the solution.
[1] I've submitted a handful of diffs and some manpages to
packages which where either ignored (without notice) or the
maintainer didn't bother to upload at all (for some months that
is).

I'm glad most Debian developers are more responsive, but such
things happen and are most frustrating.

[1] check out the changelog of afbackup for example ...

ciao, 2ri
-- 
Why is abbreviation such a long word?




Re: local facilities and official packages

2001-01-09 Thread Arthur Korn
Hi

Andres Seco Hernandez schrieb:
 Are local? facilities reserved in Debian for some purpose?

I'm not aware of any reserved local facilities, however system
log daemons provide the syslog-facility(8) script which may be
used by packages to dynamically retrieve and set up a local
facility (eg snort does this).

 Where can i find more information about syslog policy in Debian?

There is none, at least I never saw one. I try to make msyslog
behave as much like sysklogd where it makes sense, so does
Attila Szalay (syslog-ng) it seems.

ciao, 2ri
-- 
Education is what remains after one has forgotten everything he learned
in school.  -- A. Einstein




Upstream orphans wmfsm, anybody interested? [Re: wmfsm: homepage and source 404]

2001-01-05 Thread Arthur Korn
Hi

I don't know C, thus couldn't do more than keep it available.

(quick and dirty translation in [])

- Forwarded message from Stefan Eilemann [EMAIL PROTECTED] -

Date: Fri, 5 Jan 2001 10:15:23 +0100
To: Arthur Korn [EMAIL PROTECTED]
From: Stefan Eilemann [EMAIL PROTECTED]
Subject: Re: wmfsm: homepage and source 404

On Sun, Dec 31, 2000 at 03:00:27PM +0100, Arthur Korn wrote:
 Hallo Stefan.
 
 http://netpedia.net/hosting/wmfsm/
 
 Ist tot.

Hallo Arthur,

ja, all netpedia seiten sind tot.

[ all netpedia pages are gone ]

Als erstes muss ich mich bei dir entschuldigen wg. der manpage. Ich 
komme irgendwie nicht dazu.
Ich habe jetzt bei auch festgestellt, dass ich gar kein backup von
wmfsm habe :(, da ich meinen Job gewechselt habe. Mein Vorschlag 

[ he doesn't have backups, not even of wmfsm source (it's in the
debian archive though) ]

waere (...falls du zustimmst/moechtest), dass du die Website woanders
hinpackst und den Code uebernimmst, da ich in zukunft wohl eher nicht 
dazu komme.

[ he suggests that I take over wmfsm since he probably won't
have any time for it anyway ]


Stefan

- End forwarded message -

ciao, 2ri
-- 
All constants are variables.




Re: our broken man package

2001-01-05 Thread Arthur Korn
Hi

Joey Hess schrieb:
  And, anyway, caching might be done in a cronjob: look at the pagesa in

This seems to be cr^Hontrary to the idea of caching.

 That's a good idea. Another route to take is to split man into the
 rendering/caching bit and the command line man page lookup/processing/pager
 executing bit. Only the former part of the program needs to run as user man,

A man-daemon? Or a 6755 root.man rendering part?

Wouldn't simpy let every user have his own cache be much simpler
and not even too much worse, since different users tend to read
different manpages? A cronjob could collect these per-user
cached pages into a shared cache if this is really needed, and
clean up the user caches.

ciao, 2ri
-- 
All constants are variables.




Re: ITP: ttf-xtt, xfonts-xtt

2001-01-02 Thread Arthur Korn
ISHIKAWA Mutsumi schrieb:
  So, I want to separate TrueType fonts and meta datas such that
 fonts.scale and fonts.alias included in xfonts-xtt-*.

C'mon, it wont do any harm to ppl who are using LaTeX but not
X11 if they have fonts.scale and fonts.alias installed but
unused. They are not larger than 100k, are they?

ciao, 2ri




Re: ITP: ttf-xtt, xfonts-xtt

2001-01-02 Thread Arthur Korn
ISHIKAWA Mutsumi schrieb:
  For example, if ttf-xtt-* includes meta datas(fonts.alias,
 fonts.scale, tfm and so on) and when only fonts.alias update and
 upload. A user would download ttf-xtt-* package (include other files,
 they are not updated), if the user use the package only for TeX (not
 using for X).This update perhaps would not need the user.

How often will the xfonts-* package change without the ttf-*
package changing as well? Probably never, at least not the
stable packages.

The cost of having some bytes more in the Packages.gz that
_every_ user has to download (even ppl who don't know japanese)
and greater resource usage of apt is much greater than the
advantage of not having to download 3.6M once every total
eclipse (only for ppl using these packages).

ciao, 2ri
-- 
I didn't know it was impossible when I did it.




Re: test -d /usr/man mail submit@bugs

2000-12-28 Thread Arthur Korn
hi

Peter Makholm schrieb:
   for package in dpkg apt libc gpg bplay etc ; do 
 sed [...] bug.template | mail ;
   done

You'd better use [EMAIL PROTECTED], else you need a very
good asbestos suit ...

ciao, 2ri




Re: What do you wish for in an package manager?

2000-12-28 Thread Arthur Korn
Hi

Hamish Moffatt schrieb:
 Package X and package Y are not truely unrelated if they share any
 dynamic libraries, though, eg libc.
 
 So do you have any suggestion as to how this could actually be
 implemented? Even if it's actually desirable (which I dispute),
 implementation seems far from trivial.

It is trivial: link everything statically and include everything
that might be needed in each package. Welcome to
include-favorite-broken-OS.

ciao, 2ri




Re: Bug#80343: general: Lack of policy on which files should be owned by which user

2000-12-26 Thread Arthur Korn
Hi

Brian May schrieb:
  Hamish == Hamish Moffatt [EMAIL PROTECTED] writes:
 
 Hamish On Tue, Dec 26, 2000 at 11:13:13AM +1100, Brian May wrote:
  However, the idea of one UID per daemon is (IMHO) a really
  horrible solution, too, as you end up having more UIDs for
  daemons then users.
 
 Hamish Why is that a problem? There are 65536 available UIDs.
 
 Some potential problems though:
 
 - easy to hide back-door entry point in /etc/passwd if lots of entries
 exist (eg. missing password field). Whether this is by mistake
 or done on purpose by an attacker is not important, but the fact it
 is harder to detect may be important.

Regular /etc/passwd checking is done by a pretty rigid scripts
usually. It really does not matter how many entries there are in
/etc/passwd. Checking it by hand seems pointless to me.

 - As the number of entries grows, the chance that one/more entries
 will conflict with some NIS, openldap or remote NFS system increases.
 Especially since adduser, etc, do not support NIS or openldap.  I am
 not sure of the details here - can adduser assign a local user a UID
 that conflicts with that from some other source?

Then we should fix adduser and libc(PAM/NSS). I tried to get the
normal 'passwd' to change passwords on nis (well, passwdd; pam_unix
seems to be able to do this) but couldn't get it to work (I
hadn't that much time for it though).

 - harder to administrate /etc/passwd as more users exist.

Something that seems improtant to me: providing a way to use
less users/groups on some systems should be easy once every
daemon can have it's own (adduser creating system accounts with
same UID/GID comes to mind). The other way round it's harder.

ciao, 2ri




Re: Location of -doc documentation?

2000-12-25 Thread Arthur Korn
Joey Hess schrieb:
 Karl M. Hegbloom wrote:
   I just noticed that `apache-doc' puts the documentation under
   http://.../doc/apache;, while `debconf-doc' puts it under
   http://.../debconf-doc/;. 
 
 Eh? (Debconf-doc is a package, that contains some documentation files.
 It doesn't touch the web space at all.)

Well, it touches /usr/doc, and /etc/apache/srm.conf has an Alias
/doc/ /usr/doc/. HTH

ciao, 2ri




Re: What do you wish for in an package manager?

2000-12-25 Thread Arthur Korn
Hi

Mark Seaborn schrieb:
 I want a system where I can install multiple versions of a library (or
 any package really) and say which version I want each program on the
 system to use, possibly on a per-user basis.  The present system is a
 disaster waiting to happen:  If I install a package from unstable, it
 often wants to replace my version of libc from stable with one from
 unstable.
[...]

You actually can install (hypotetical) libfoo0
(/usr/lib/libfoo.so.0.3.1) and libfoo1
(/usr/lib/libfoo.so.1.0.9) at once, and that's why Debians
shared library dependencies work (with packages gradually
upgrading to the new library). Unfortunately more and more
library packages do no more properly feature the entire soname
in the package name, which can cause mayham.

And if you want to install packages from unstable on a stable
system you ether take the binary package and everything it
depends on, or you apt-get -b source it. If all library packages
are made properly, you can't get around this with fancy package
management.

Running programs with another than the standard version of a
library can be done with LD_PRELOAD (ld.so(8)).

ciao, 2ri




Re: apt-move problem

2000-09-07 Thread Arthur Korn
Peter S Galbraith schrieb:
 My current problem with apt-move is that it wants to delete every
 single deb file I have

For my archive it was to late:

19M /home/pub/debian

That was ~250M before ... oops. Time to use http and squid
instead ...

ciao, 2ri
-- 
Note that there are two possible orientations of the log. If the end with the
larger diameter is facing downstream, the log is said to be big-endian;
otherwise, it is little-endian.
-- Philip Willoughby [EMAIL PROTECTED] on Segfault.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: build question

2000-09-05 Thread Arthur Korn
David Starner schrieb:
 On Tue, Sep 05, 2000 at 01:29:02AM +0200, Tom Cato Amundsen wrote:
  On Mon, Sep 04, 2000 at 07:19:11PM +, michael d. ivey wrote:

   my main server is potato.  is it bad for me to be building packages
   there if they are destined for woody?  should i start building on a
   woody box?
   
  If possible, your package should depend on packages in potato only.
  Then users won't be forced to install other unstable packages,
  just to try out your package.

 Contrary to Tom, though, if packages are destined for woody, packages 
 should be built on woody, because that's how the build demons will 
 build them, that's how people will run them, and that's how they
 will eventually be released. It will also help shake out bugs in
 unstable libraries.

That sounds reasonable.

 If you want to build them so that potato users can use them,
 do so and store them in a directory on master or a private
 machine and tell people how to get them.

Or just educate people on how to use dpkg-buildpackage (apt-get -b
source). This would be even easier if dpkg-buildpackage would
handle Build-Relations itself. I like debian source
packages ...

ciao, 2ri
-- 
They are really completely different things, so don't mix them up, but they
have a close relation to each other.
-- http://hurddocs.org/whatis/translator.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: X and runlevels

2000-09-04 Thread Arthur Korn
Paul Slootman schrieb:
 On Mon 04 Sep 2000, Ethan Benson wrote:

 Debhelper (and one of the other helper things) does this, if you 
 don't call dh_installinit with the --no-restart-on-upgrade (or such)
 option. I guess the reasoning is that (a) you're upgrading in multiuser
 mode because debian lets you :-) (b) in multiuser mode the daemon was
 running.

Running start-stop-daemon without --oknodo for restart) would
probably also solve the problem (you do set -e, do you?). It
would yell if it doesn't find the daemon running and exit.

 It's unfortunate that there's no easy way to find the current runlevel
 (the usual who -r from Solaris etc. doesn't work), otherwise this
 piece of code could be used:
 
   RL=`who -r`
   if [ -x /etc/rc$RC.d/S??$PKGNAME ]; then
   /etc/rc$RC.d/S??$PKGNAME start
   fi

14:27:10 [EMAIL PROTECTED]:~$ sudo runlevel
N 2

 That's ignoring file-rc, unfortunately. Is there an easy way of
 determining whether a certain init.d script should be started in
 the current runlevel that works also with file-rc ?

Probably we should just make /etc/init.d/foobar restart _not_
start anything if the deamon was not running before. It can be
done with little effort there, and works with file-rc.

ciao, 2ri
-- 
The light at the end of the tunnel is the headlight of an approaching
train.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: why apt/dpkg not using bzip2

2000-09-04 Thread Arthur Korn
Hello.

Adrian Bunk schrieb:
 My suggestion for the Packages file is:
 
 There's a Packages.bz2 additionally to the Packages.gz . apt downloads by
 default the Packages.bz2, but you can tell apt to fetch the Packages.gz
 instead if you do have a slow machine. This solution has the advantage
 that there are no problems with old versions of apt (the Packages.gz is
 still present), and if you don't want the .bz2 you can still get the .gz .

I don't understand this hysteria about compressing
Packages-files. IMO it would be _much_ better (bandwith and
processing-speed wise) to have it uncompressed on the servers
and rsync it. How often did you have to download that whole
damned 800k Packages.gz of unstable just because one single
package was upgraded?

apt-move uses rsync to update it's Packages, and it's a real
improvement over the sledgehammer method.

ciao, 2ri, sitting behind 64k/s ISDN, yawning
-- 
The light at the end of the tunnel is the headlight of an approaching
train.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Machine-specific optimizations

2000-09-01 Thread Arthur Korn
Hello.

Alisdair McDiarmid schrieb:
 On Thu, Aug 31, 2000 at 01:49:13PM -0700, Sean 'Shaleh' Perry wrote:

  you always have the option of using 'apt-get source' to recompile a package,
  then place it on hold and we wont touch it.
 
 I've tried doing this occasionally -- more often to change a
 compile-time feature than optimise for CPU -- and it's not very
 convenient. I mean, the apt-get source couldn't be easier, but unless
 I put the package on hold, apt `upgrades' to the *same* version on
 the very next apt-get upgrade.

Is there a convenient way to put a package on hold? I couldn't
figure anything out form the dpkg and apt-get manpages. If I
have to start dselect every time I want to put something on hold
this is certainly not how it should be. (Ever used dselect on a
9600 serial console? It's fun ;).

ciao, 2ri
-- 
Siddhartha tut nichts, er wartet, er denkt, er fastet, aber er geht durch die
Dinge der Welt hindurch wie der Stein durchs Wasser, ohne etwas zu tun, ohne
sich zu rühren; er wird gezogen, er lässt sich fallen. [...] Es ist das, was die
Toren Zauber nennen und wovon sie meinen, es werde durch die Dämonen bewirkt.
-- Hermann Hesse, Siddhartha


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Bug#70269: automatic build fails for potato

2000-08-30 Thread Arthur Korn
Hello.

Anand Kumria schrieb:
 Not having the helper packages included in the autobuild system appears to
 benefit, at most, around ~470 packages.

May I ask how they benefit?

It's only a (little) burden on the packages that use debhelper,
but I can't see any benefits for packages not using it. Nobody
will force debhelper on anyone.

As soon as you want to build something you will most probably
end up installing debhelper anyway, thus it's only wasted space
on the mirrors if all these hundreds of packages that use
debhelper have to declare this in their Build-Depends:.

On the other hand it probably makes counting them easier ... ;)

ciao, 2ri
-- 
0 and 1. Now what could be so hard about that?




<    1   2