Bug#506069: cone does not appear in mail-reader virtual package
Package: cone Version: 0.74-2 Severity: normal Cone does not appear in mail-reader virtual package list. Consequently, inferior mail-readers are automatically installed, when cone would be better. Adding Provides mail-reader to dependencies should fix. -- System Information: Debian Release: lenny/sid Architecture: i386 (i686) Distribution: IYCC Distribution Release: 8.09.1 Kernel: Linux 2.6.24-21-generic (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cone depends on: ii libc6 2.7-10ubuntu4 GNU C Library: Shared libraries ii libfam0 2.7.0-13 Client library to control the FAM ii libgcc1 1:4.2.4-1ubuntu3 GCC support library ii libldap-2.4-2 2.4.9-0ubuntu0.8.04.1 OpenLDAP libraries ii libncursesw5 5.6+20071124-1ubuntu2 Shared libraries for terminal hand ii libssl0.9.8 0.9.8g-4ubuntu3.3 SSL shared libraries ii libstdc++64.2.4-1ubuntu3 The GNU Standard C++ Library v3 ii libxml2 2.6.31.dfsg-2ubuntu1.2 GNOME XML library cone recommends no packages. -- no debconf information -- Loye Young Isaac Young Computer Company Laredo, Texas http://www.iycc.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484129: Better way to handle tasks.
However, there is no equivilant source of information for packages apt-installed by d-i. Could there be one? Well, if you're interested in having the same safeguard mechanism in place for these packages. I have made a first one by grepping through the source code. As apt-install is used in code, we can't really think of automating the process of creating such list. The debian-installer team might probably be able to maintain a list in its source repository. Would that be fine for the release-team? Our company puts the [distro]-tasks.desc file in the repository in the same directory as Packages.gz. We make aptitude download the .desc to the right place on every update. Consequently, all we have to do to maintain the tasks is edit a text file in the repository, which automatically gets deployed with every update. It works for us, and I think it would go a long way to bringing visibility and ease of management to tasks. -- Loye Young Isaac Young Computer Company Laredo, Texas http://www.iycc.biz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#122304: Not fundamentally an apt-get problem
I don't think this is an apt-get problem. I use aptitude exclusively, and I get the same problem. The behavior started only recently, so I think the problem lies in some package that both apt-get and aptitude depend on. The issue won't really be solved until the real source of the issue is discovered and corrected. Loye Young -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428620: [pkg-wpa-devel] Bug#428620: Conflicting advice regarding security
On Tuesday, July 3, 2007 5:14:29 pm Kel Modderman wrote: Does the emphasis on waaay indicate you want it moved somewhere else? My personal feeling is that it should be in a more natural place to look for it, and that security issues should be more prominent. At the bottom of a file dealing with modes of operation seems not intuitive. Why not just give the security issues their own README.security (or similar)? We'd have to provide the generic group wheel too. I think that is not going to happen. I was of course using the example the documentation provided. Perhaps creating a group wireless might not be a terrible idea, though. README.modes suggests perms of 0600 because it describes use cases where wpa_supplicant is started as system daemon (by root) only. Yes, that's right. The question is What should be the recommended security precautions? Once that's decided, sensible defaults should be set up and the documentation conformed. I see three options: (1) Set file permissions to 660 as default, with owner=root and group=root. Run as a system daemon, it would operate the same as 600. Run as a user application with a special group for wireless users, as the documentation suggests, it would automatically work when the sys admin followed the directions. (2) Keep file permissions the way they are, but add lingo to the documentation telling the sys admin to change the file permissions if he wants to allow one or more users to configure wireless without giving them su powers. (3) Set file permissions to 660, owner=root, group=wireless. Run as a system daemon, without any user in the wireless group, it's the same as 600. If the sys admin wants one or more users to be able to configure the wireless connection, he simply adds the users to the wireless group. My choice is number 3. Carrying a laptop around inevitably requires configuring the wireless settings for various local wireless network, and it's hard to predict in advance what is going to be required. Inevitably, the sys admin will have to give some sort of enhanced privileges to the user carrying the laptop. If the sys admin and the user are the same person, our buddy sudo does the trick and it's no big deal. But if the sys admin is in the IT department and the user is some salesman or consultant schlepping around in hotels and airports, the better part of valor would be to set up a wireless group and put the hapless users in that group. Option 3 would be a sensible default for file permissions, and reduce the number of configuration steps, no matter what the sys admin decided. To carry it a step farther, the install script could ask which users should be in the wireless group, providing a list of users to select among. Thanks, Kel. Thank YOU! Loye Young -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428620: Conflicting advice regarding security
Package: wpasupplicant Version: 0.5.7 /usr/share/doc/wpasupplicant/README.modes.gz advises (waaay down at the bottom) to set permissions to 0600 for both /etc/network/interfaces and /etc/wpa_supplicant/wpa_supplicant.conf. /usr/share/doc/wpasupplicant/examples/README.wpa_supplicant.conf.gz advises that by setting GROUP=wheel, non-root users can use the control interface, but wpa_supplicant can run as root. However, if wpa_supplicant.conf is 0600, only root can read the file and client apps fail because they cannot read configuration file. Would it make sense to: chmod root:wheel wpa_supplicant.conf chmod 0660 wpa_supplicant.conf by default? Happy Trails, Loye Young http://www.iycc.biz Laredo, Texas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428620: Conflicting advice regarding security
Original post should read: chown root:wheel wpa_supplicant.conf L -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
