Re: auditd as logrotate replacement?
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
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
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]
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
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
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
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
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?
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
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?
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?
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
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
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
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
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
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
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?