Re: mass bug filing for undefined sn?printf use
Evgeni Golov writes: > On Sun, 28 Dec 2008 09:53:40 +0100 Adeodato Simó wrote: > >> Evgeni Golov >>desmume (U) > > Forwarded upstream, they'll fix that asap. thanks for taking care for this! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Override changes standard -> optional
[...] > > Actually, I misspoke in saying that mtr-tiny is the only traceroute we have > by default. iputils-traceroute is also installed at Priority: important; but > iputils-traceroute is far less useful on modern networks than mtr-tiny is. > > If traceroute belongs in important, then mtr belongs in standard. > I'd rather say that the priority of iputils-traceroute should be downgraded as well. > > If so, I doubt that the the output of strace will be very useful to those, > > The same argument easily applies to the output of 'dig', which is included > in dnsutils at Priority: standard. Nevertheless, having it available by > default is useful for troubleshooting purposes when a problem has been > escalated to the corresponding "support" personnel (via a Debian bug report, > by handing your computer to your local expert, or whatever). > I do see one important fact here: Both, some traceroute tool and dig, are useful in troubleshooting network problems, and its output will be useful for support personnel. While the latter is also true for strace and friends, network problems may prevent one from fetching the corresponding packages from Debian mirrors. Summarizingly I think that network troubleshooting tools should have a higher chance to stay with Priority: standard than other debugging tools. Still, there must be some consistency: If dig goes in, then some traceroute implementation should do so as well, or (my preferred position) all of them should be demoted. Best, Michael pgpllqN0hAZFV.pgp Description: PGP signature
Re: Override changes standard -> optional
Le mercredi 31 décembre 2008 à 10:09 +1100, Ben Finney a écrit : > This one is probably not *directly* useful to users of a standard > system, but I'm not sure what effect the change in priority has for > the presence of this package on installation media. This package is currently in standard only because other standard packages depend on it. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Override changes standard -> optional
[...] > > > I could buy that for mtr-tiny, but which average user can do anything > > meaningful with strace so that it needs to be in standard? If you need > > it you have bug, and the average user will report that $upstream > > (debian, developer, wherever). And can then install it if asked to > > strace something. > > Having the tool available by default means one less step that users need to > follow in order to debug. > [...] My main concern is that user <-> debug relation, which I doubt. "standard" is meant for all users, not only for the developer/sysadmin subset. I do agree that installing the debugging tool, when directed to do so, is one additional step, but it's probably the easiest one. Best, Michael pgpoLyhrv62U0.pgp Description: PGP signature
Bug#510321: ITP: libjcip-annotations-java -- Java Concurrency In Practice annotations library
Package: wnpp Severity: wishlist Owner: Rafal Lewczuk * Package name: libjcip-annotations-java Version : 20060626 Upstream Author : Brian Goetz, Tim Peierls * URL : http://www.jcip.net * License : CC Attribution 3.0 Programming Lang: Java Description : Java Concurrency In Practice annotations library This is a package with annotation classes from Java Concurrency In Practice book. These annotations are used to describe thread-safety prmises of various parts of Java code. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Override changes standard -> optional
On Tue, Dec 30, 2008 at 09:00:04PM +0100, Frans Pop wrote:
> For most languages tasksel will automatically install relevant
> dictionaries. It currently does not do so for English _because_
> those packages are priority standard (and have been for a long
> time). IMO we should be consistent between languages in that
> respect, and especially for English.
Fully agreed.
... but how does this "cooperate" with the need pointed out by Russ of
having a /usr/share/dict/words file? Do the dictionaries installed by
tasksel provide such a file (in whatever language)?
If they do, I'd be happy about not having the package priority
Standard, but tasksel installing them. If someone stops the
installation before the tasksel step then it's too bad, we cannot
decide the dictionary for her.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Override changes standard -> optional
On Tue, Dec 30, 2008 at 01:34:35PM +0100, Joerg Jaspert wrote:
> In case you see a good reason why the above is wrong, feel free to reply
> stating it. We currently can't see any of the packages living up to the
> policy definition of standard.
I would welcome the following packages to remain Standard:
> strace
Rationale: every day sysadm local debugging tool, at least IME.
> mtr-tiny
Rationale: every day sysadm network debugging tool *and* also user
"debugging" tool to understand what is not working in the connection
to their own remote server/website.
As a user, I'd be very annoyed to login on a machine which is missing
both traceroute and mtr.
> finger
Less important than the above two, this one is still one of the tool
which is still taught in basic *NIX classes as the way to inspect
files such as ".plan". Also, there are still some "interesting"
finger-based services out there.
Yes, all of them are disappearing, but I suggest we keep finger for
Lenny and then demote it to non-standard for Lenny+1.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris
7 z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>-
http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en
veux pas si je te tutoie sempre uno zaino ...| ..: | Je
dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: I hereby resign as secretary
Manoj Srivastava writes ("I hereby resign as secretary"):
> I am hereby resigning as secretary, effective immediately.
I'd just like to join all the other people saying that it's sad that
we have come to this. As you know I haven't always agreed with your
decisions :-) but they have always seemed to be me to be taken in good
faith and with the best will.
Please don't leave us completely and I hope we can try to make Debian
a more pleasant place.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: mass bug filing for undefined sn?printf use
On Tue, Dec 30, 2008 at 08:03:13PM +0100, Arthur de Jong wrote:
> I've just performed a test with the following code on my system (sid,
> hardening-wrapper not installed, compiled with gcc without any extra
> flags):
>
> char buf[20];
> strcpy(buf,"FOO");
> snprintf(buf,sizeof(buf),"%s%s",buf,"BAR");
> printf("%s\n",buf);
> strcpy(buf,"BAR");
> snprintf(buf,sizeof(buf),"%s%s","FOO",buf);
> printf("%s\n",buf);
>
> which returned
>
> BAR
> FOOFOO
Changing your code to "sprintf" (since snprintf unfortunately tends to be
in the minority still), the output for the first changes to "FOOBAR".
--
Kees Cook@debian.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: mass bug filing for undefined sn?printf use
On Sun, Dec 28, 2008 at 09:53:40AM +0100, Adeodato Simó wrote: > > Attached is a list of affected packages, > > Piping through dd-list(1) gives: > Aurelien Jarno >med-fichier >sdlperl (U) > sdlperl is fixed in both unstable and experimental. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aure...@debian.org | aurel...@aurel32.net `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Override changes standard -> optional
On Wed, 2008-12-31 at 15:18, Stefano Zacchiroli wrote: > On Tue, Dec 30, 2008 at 01:34:35PM +0100, Joerg Jaspert wrote: > > In case you see a good reason why the above is wrong, feel free to reply > > stating it. We currently can't see any of the packages living up to the > > policy definition of standard. > I would welcome the following packages to remain Standard: > > strace > Rationale: every day sysadm local debugging tool, at least IME. I agree. > > mtr-tiny > Rationale: every day sysadm network debugging tool *and* also user > "debugging" tool to understand what is not working in the connection > to their own remote server/website. > > As a user, I'd be very annoyed to login on a machine which is missing > both traceroute and mtr. Again, I agree I'd like to mention tcsh. More than ten years I administer Debian machines and tcsh was always there. -- Kind regards, Milan signature.asc Description: Digital signature
Re: RFC: adding pre-depends to libpam-modules for lenny
On Sun, 28 Dec 2008 00:57:22 -0600, Steve Langasek wrote: >The issue is that, in order to reliably ensure that a user (such as the >admin) is not locked out by xscreensaver or xlockmore in the middle of an >upgrade, The release notes strongly suggest not doing the upgrade from within an X session, so I'd regard a lock-out due to an X screensaver kicking in an admin error. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510350: ITP: snakefood -- Python dependency grapher
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: snakefood Version : 1.3.1 Upstream Author : Martin Blais * URL : http://furius.ca/snakefood/ * License : GPL2+ Programming Lang: Python Description : Python dependency grapher Generate dependency graphs from Python code. This dependency tracker package has a few distinguishing characteristics: . * It uses the AST to parse the Python files. This is very reliable, it always runs. * No module is loaded. Loading modules to figure out dependencies is almost always problem, because a lot of codebases run initialization code in the global namespace, which often requires additional setup. Snakefood is guaranteed not to have this problem (it just runs, no matter what). * It works on a set of files, i.e. you do not have to specify a single script, you can select a directory (package or else) or a set of files. It finds all the Python files recursively automatically. * Automatic/no configuration: your PYTHONPATH is automatically adjusted to include the required package roots. It figures out the paths that are required from the files/directories given as input. You should not have to setup ANYTHING. * It does not have to automatically 'follow' dependencies between modules, i.e. by default it only considers the files and directories you specify on the command-line and their immediate dependencies. It also has an option to automatically include only the dependencies within the packages of the files you specify. * It follows the UNIX philosophy of small programs that do one thing well: it consists of a few simple programs whose outputs you combine via pipes. Graphing dependencies always requires the user to filter and cluster the filenames, so this is appropriate. You can combine it with your favourite tools, grep, sed, etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#510350: ITP: snakefood -- Python dependency grapher
This looks like a very useful application. On Wed, Dec 31, 2008 at 11:27 AM, Sandro Tosi wrote: > * It works on a set of files, i.e. you do not have to specify a >single script, you can select a directory (package or else) or a >set of files. It finds all the Python files recursively >automatically. > * Automatic/no configuration: your PYTHONPATH is automatically >adjusted to include the required package roots. It figures out the >paths that are required from the files/directories given as >input. You should not have to setup ANYTHING. > > [...] > > Graphing dependencies always requires the user > to filter and cluster the filenames, so this is appropriate. Maybe I'm missing something, but these statements seem inconsistent. If the user always has to filter the filenames, what does it mean for it to automatically find the Python files recursively? In what sense is it automatic? I think you mean something more specific than just saying the user must always filter "filenames" since it's unclear what that means. Cheers, Daniel -- Daniel Moerner -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Upgrade Pre-Report and Wireless Documentation
Hello, I was testing my USB WLAN stick on a lenny system blackbox:~# lsusb |grep Link Bus 008 Device 002: ID 2001:3c00 D-Link Corp. [hex] DWL-G122 802.11g rev. B1 [ralink] blackbox:~# It was running flawless on an etch laptop. The intention was to avoid having an upgraded lenny laptop without wireless. I will send in an upgrade report to help to make lenny even better :-) [footnote: I was wondering if the debian-release list is the right place or if a bug report against upgrade-reports is appropriate for an upgrade-report.] Getting the WLAN stick running was not smooth (and it still does not yet work in my wpa wireless network). But this is a different issue: http://lists.debian.org/debian-kernel/2008/12/msg01257.html While going through the wireless setup for the stick, I noticed, that I am pretty lost, when it comes to the wireless configuration in /etc/network/interfaces.The interfaces(5) man page points to iwconfig(8) and wireless(7) The wireless manpage and /usr/share/doc/wireless-tools/DISTRIBUTIONS.txt.gz refer to Debian 3.0 (or later), I was wondering if this information is outdated? The wpa-* statements in /etc/network/interfaces guided me to to wpa_supplicant which comes with good documentation in /usr/share/doc/wpasupplicant/. Does that mean that the wireless pointer in interfaces(5) is incomplete? I am wondering if there is documentation for the wireless setup in /etc/network/interfaces to get started for an inexperienced wireless user like me and I just did not find the getting started document. If not, I am wondering if it is worth to add a reference into the interfaces man page to wpasupplicant and add a paragraph what the wireless-tools and what wpasupplicant is used for. I am also frequently looking for example configurations for the most common setups (WEP, WPA, WPA2, etc...), but I did not find these either. But I cannot tell if these would cover a subset of APs that this would be worthwhile. I cc'ed Anthony, because he is maintainer of the ifupdown package which contains the interfaces manpage... Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdor...@web.de jabber: rdor...@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510356: ITP: clojure -- a Lisp dialect for the JVM
Package: wnpp Severity: wishlist Owner: Peter Collingbourne * Package name: clojure Version : 0.0.20081217 Upstream Author : Rich Hickey * URL : http://clojure.org/ * License : Eclipse Public License 1.0 Programming Lang: Java, Clojure Description : a Lisp dialect for the JVM Clojure is a dynamic programming language that targets the Java Virtual Machine. It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection. Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Override changes standard -> optional
On Wednesday 31 December 2008 11:32, Frans Pop wrote: > Russell Coker wrote: > > Frans Pop wrote: > > > Not really. SELinux is not even close to functional after a standard > > > installation. For one thing, it gets installed *after* the initrd gets > > > generated and the initrd does not get regenerated, so the admin has to > > > do that manually after rebooting into the installed system. > > > > There is no need to regenerate an initrd in Debian. > > I just did a standard i386 install using the instructions on the wiki [1] > (which BTW look to be rather outdated in several respects). They were, I have just made some significant changes. > I did my previous test at the time of the discussion in September and > remember that I did need to regenerate the initrd then to get rid of some > errors. It does seem better now. > > However, I still had to regenerate the initrd because of the instruction > to add "no_static_dev="1" for udev. Previously I hadn't realised that was possible. It's mostly a cosmetic issue. Some daemons recursively scan /dev and generate some audit messages if you don't do it. But there is no security issue. I have all my SE Linux machines running without that change. > I also feel that as long as you need to check for instructions in a wiki > and manually edit various config files (most importantly in /etc/pam.d) > in order to activate SELinux support that there is very little gain in > having the packages pre-installed. While SE Linux is disabled by default there is little benefit in having the packages pre-installed. The wiki instructions are not overly complex (now that I have improved them and referenced some new code features). http://doc.coker.com.au/computers/installing-se-linux-on-lenny/ I have simpler instructions at the above URL. They can be summarised as the following: apt-get install selinux-policy-default selinux-basics selinux-activate reboot postfix-nochroot (optional) selinux-config-enforcing > P.S. Isn't selinux-basics required? It seems to be, but it was not > priority standard... You can run SE Linux without it, but you probably won't want to. It should probably have the same status as selinux-policy-default. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: adding pre-depends to libpam-modules for lenny
On Wed, Dec 31, 2008 at 08:01:37PM +0100, Marc Haber wrote: > On Sun, 28 Dec 2008 00:57:22 -0600, Steve Langasek > wrote: > >The issue is that, in order to reliably ensure that a user (such as the > >admin) is not locked out by xscreensaver or xlockmore in the middle of an > >upgrade, > The release notes strongly suggest not doing the upgrade from within > an X session, so I'd regard a lock-out due to an X screensaver kicking > in an admin error. The information in the release notes is outdated in this regard, gdm doesn't get restarted on upgrade so there's no particular danger of botching the upgrade by running apt under gdm. Thanks, I've updated the release notes. Also, the release notes only say that you shouldn't run the upgrade *from* such X sessions, this says nothing about leaving X sessions running for other users during an upgrade. (Though it's implicit that if you're not using gdm, these users are going to be mad at you when their sessions suddenly die.) Finally, while a stable dist-upgrade is going to include updates to libpam-modules and the *dm package in the same run, users tracking testing or unstable could easily find themselves upgrading libpam-modules where they believed it was safe and hitting this problem in the process. So a general fix is still needed for future ABI changes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Override changes standard -> optional
Russell Coker wrote: > On Wednesday 31 December 2008 11:32, Frans Pop wrote: >> Russell Coker wrote: >> I just did a standard i386 install using the instructions on the wiki >> [1] (which BTW look to be rather outdated in several respects). > > They were, I have just made some significant changes. Thanks a lot for that. BTW, wouldn't it make sense to have separate wiki pages with setup info per release? The instructions for Etch probably are still valid. > While SE Linux is disabled by default there is little benefit in having > the packages pre-installed. I'm glad we agree on that. My personal opinion is that having selinux at priority standard is not the correct choice for Debian. It's good that we've tried it, but it's also good that we've now reverted it. I'll be happy to work with you on designing some alternative way to (optionally) install *and* activate SELinux during new installations. Main restriction there will be that policy forbids us to modify config files of other packages, so any activation of SELinux in packages such as the changes in PAM config files will need to be supported by the relevant packages, probably through debconf settings. From the few tests I've done SELinux has matured a lot and the Debian packaging has improved tremendously, mainly through your efforts. There are a lot less issues after activation then there were for Etch. I hope that trend will continue, but especially that users will be able to get more support. However, I also don't yet see SELinux becoming a standard service on all Debian systems. It's just too complex a framework for that. Cheers and happy new year, FJP signature.asc Description: This is a digitally signed message part.
Re: mass bug filing for undefined sn?printf use
On Sun, Dec 28, 2008 at 12:42:46AM -0800, Kees Cook wrote: > Hi, > > I'd like to seek advice before I perform a mass-bug filing for this > unstable (though semi-common) use of "sprintf" and "snprintf": [...] > pcregrep -M 'sprintf\s*\(\s*([^,]*)\s*,\s*"%s[^"]*"\s*,\s*\1\s*,' While fixing one of the affected packages, I discovered that it was using similarly problematic syntax to act as a strcat replacement of the form 'sprintf(buf, "%s\n", buf)', which that regexp didn't catch. I can't imagine that's a common mistake, but it's easy enough to match on as well: pcregrep -M 'sprintf\s*\(\s*([^,]*)\s*,\s*"%s[^"]*"\s*,\s*\1\s*[,)]' > gabedit > gromacs > openbabel All pending upload, thanks. -- Nicholas Breen nbr...@ofb.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Override changes standard -> optional
On Thursday 01 January 2009 13:55, Frans Pop wrote: > > They were, I have just made some significant changes. > > Thanks a lot for that. BTW, wouldn't it make sense to have separate wiki > pages with setup info per release? The instructions for Etch probably are > still valid. It would. In preparation for that I made my personal web page about it include Lenny in the name. Of course Etch SE Linux isn't particularly functional without a set of extra packages that are only on my personal web site. I have been considering removing those packages due to an apparent lack of interest. > I'll be happy to work with you on designing some alternative way to > (optionally) install *and* activate SELinux during new installations. > Main restriction there will be that policy forbids us to modify config > files of other packages, so any activation of SELinux in packages such as > the changes in PAM config files will need to be supported by the relevant > packages, probably through debconf settings. Currently in Debian booting the kernel with "selinux=1" is needed to enable SE Linux. This is in contrast to RHEL, CentOS, and Fedora where it's enabled by default and booting with "selinux=0" is required if you want to disable it. So if the user typed "install selinux=1" from the installer then the install kernel would have SE Linux enabled, and querying /proc/cmdline for selinux=1 could be used for later stages of installation to determine whether SE Linux was desired. Anaconda (the Red Hat installer) looks for selinux=0 to change it's installation options. Then if SE Linux was enabled we could load the policy at a suitable time during the installation process and have all the files correctly labelled at the first boot. The Debian SE Linux policy is highly modular (as opposed to every Red Hat release I've tried which only uses the module support for end-user modifications) and modules are automatically selected to match the packages you have installed. This results in less kernel memory being used, but means that we need to install the modules before installing packages (as opposed to the alternatives which are all ugly). Can we have an extension to APT to make it call a script before it installs a set of packages? NB It doesn't really matter if the sysadmin decides to abort the installation. Having a few unused policy modules doesn't do any harm, it's only when you have a couple of hundred of them that you start wasting kernel memory. > From the few tests I've done SELinux has matured a lot and the Debian > packaging has improved tremendously, mainly through your efforts. Thanks! Also Manoj has been doing some great work recently and we are building on a heap of work from all the other DDs who have worked on this and the code from the NSA, Tresys, Red Hat, and others. > There > are a lot less issues after activation then there were for Etch. I hope > that trend will continue, but especially that users will be able to get > more support. Yes, I have a number of exciting things planned for this year. One of which requires getting bittorrent in Lenny working to serve my torrents - any advice from a bittorrent expert would be appreciated off-list. NB I have not filed a bug report against bittorrent as I'm not sure whether it's a bug or whether I just stuffed up. > However, I also don't yet see SELinux becoming a standard service on all > Debian systems. It's just too complex a framework for that. "Yet" being the relevant word. I've been working on this for more than 7 years and it just keeps getting better. In time I think that I will get you and the other members of the Debian Installer team to agree with me. NB I would be happy with a single question being asked of the user "Do you want SE Linux?" with "yes" and "no" being menu options. I don't plan to push for SE Linux to be made the default for the Debian install in the same way as it is for Fedora and RHEL (but I would be happy if it happened). > Cheers and happy new year, Thanks, same to you! -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Override changes standard -> optional
Joerg Jaspert wrote: finger It's been a while since I've seen a useful finger server, I think it's fine to drop this too. db.debian.org, but that doesnt need it standard. For what it's worth finger's local features are still important. I've recently seen a professor explain to a class of students mostly unfamilar with Unix-style systems that the command to list the users current logged in was "finger". Obviously the normal command for this purpose is "who". Also AFAIK finger is the only program that normally exposes the contents of the /etc/passwd GECOS feild, as well as the .plan and .project file. I'll admit those are rarely used today, but there is some major tradition behind finger being a basic UNIX component. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
