Bug#608272: puppet-common: Please add a logcheck ignore line for executed successfully
Package: puppet-common
Version: 2.6.2-3
Severity: wishlist
First, thanks for maintaining Puppet, its appreciated.
Please add the following line to /etc/logcheck/ignore.d.server/puppet-common
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ puppet-agent\[[0-9]+\]: .* executed
successfully$
The rationale is:
1) executed successfully is (spammy) good news
2) logcheck is intended to filter out good news, especially spammy good news.
3) Therefore filter out executed successfully lines
Thanks!
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages puppet-common depends on:
ii adduser 3.112+nmu2 add and remove users and groups
ii facter 1.5.7-1 a library for retrieving facts fro
pn libopenssl-ruby none (no description available)
ii libruby [libxmlrpc-ruby] 4.5 Libraries necessary to run Ruby 1.
ii libshadow-ruby1.81.4.1-8 Interface of shadow password for R
ii ruby1.8 1.8.7.302-2 Interpreter of object-oriented scr
puppet-common recommends no packages.
puppet-common suggests no packages.
-- Configuration Files:
/etc/logcheck/ignore.d.server/puppet-common [Errno 13] Permission denied:
u'/etc/logcheck/ignore.d.server/puppet-common'
/etc/puppet/puppet.conf changed [not included]
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608282: Please fracture /etc/munin/plugin-conf.d/munin-node
Package: munin-node Version: 1.4.5-3 Severity: wishlist Thanks for maintaining munin, its appreciated and useful. Please fracture /etc/munin/plugin-conf.d/munin-node into one config file for each component. This would make upgrades a little cleaner. For example, I always modify: [df*] env.exclude none unknown iso9660 squashfs udf romfs ramfs debugfs env.warning 92 env.critical 98 to the following: [df*] env.exclude none unknown iso9660 squashfs udf romfs ramfs debugfs udev tmpfs env.warning 92 env.critical 98 As the lack of the relatively nonuseful udev and tmpfs make the graph look better. (Also modifying the default for df might be a good idea in general... do people really monitor the size of their udev?) If that lived in a separate file, then upgrades to hddtemp2 or whatever would not require modification of the df file. Ideally, in my opinion, a default config installation should have a completely empty /etc/munin/plugin-conf.d directory... that directory should only contain locally configured overrides not package defaults plus local overrides. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages munin-node depends on: ii adduser 3.112+nmu2 add and remove users and groups ii gawk 1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr ii libnet-server-perl0.97-1 An extensible, general perl server ii lsb-base 3.2-23.1 Linux Standard Base 3.2 init scrip ii munin-common 1.4.5-3network-wide graphing framework (c ii perl 5.10.1-16 Larry Wall's Practical Extraction ii procps1:3.2.8-9 /proc file system utilities Versions of packages munin-node recommends: ii libnet-snmp-perl 5.2.0-4Script SNMP connections Versions of packages munin-node suggests: pn acpi | lm-sensors none (no description available) pn ethtool none (no description available) pn hdparm none (no description available) pn libcache-cache-perl none (no description available) ii libcrypt-ssleay-perl0.57-2 Support for https protocol in LWP ii libdbd-mysql-perl 4.016-1 Perl5 database interface to the My pn libdbd-pg-perl none (no description available) ii liblwp-useragent-determ 1.04-1 LWP useragent that retries errors pn libnet-irc-perl none (no description available) ii libnet-ssleay-perl 1.36-1 Perl module for Secure Sockets Lay ii libtext-csv-xs-perl 0.73-1 Perl C/XS module to process Comma- ii libwww-perl 5.836-1 Perl HTTP/WWW client/server librar ii libxml-simple-perl 2.18-3 Perl module for reading and writin ii logtail 1.3.13 Print log file lines that have not ii munin 1.4.5-3 network-wide graphing framework (g pn munin-java-plugins none (no description available) ii munin-plugins-extra 1.4.5-3 network-wide graphing framework (u ii mysql-client-5.1 [mysql 5.1.49-3 MySQL database client binaries ii net-tools 1.60-23 The NET-3 networking toolkit ii python 2.6.6-3+squeeze2 interactive high-level object-orie ii ruby4.5 An interpreter of object-oriented pn smartmontools none (no description available) -- Configuration Files: /etc/munin/munin-node.conf changed [not included] /etc/munin/plugin-conf.d/munin-node [Errno 13] Permission denied: u'/etc/munin/plugin-conf.d/munin-node' -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#392834: simh: vax with ethernet networking?
On Tue, Mar 23, 2010 at 12:22:08PM +0100, Nico Haase wrote: Hi, Is there any news about network support in SimH? Regards Nico This weekend, I hope -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549638: afflib-tools and simh: error when trying to install together
On Mon, Oct 05, 2009 at 08:35:22AM +0200, Ralf Treinen wrote: Package: simh,afflib-tools Version: simh/3.8.1-1 Version: afflib-tools/3.3.6+dfsg-3 Usertags: edos-file-overwrite This is a serious bug as it makes installation fail. Possible solutions are to have the two packages conflict, to rename the common file in one of the two packages, or to remove the file from one package and have this package depend on the other package. File diversions or a Replace relation are another possibility. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): usr/bin/s3 OK my interpretation of the situation, is you afflib guys really need the name s3 because that is the full name of the amazon s3 service you're trying to access, and the simh s3 is merely the short name for the System/3 emulator. afflib folks please confirm or deny the accuracy of my interpretation. If I'm correct I think the logical solution is I extend the name of the System/3 emulator from s3 to system3 (err I have to verify that is not otherwise in use... maybe I'll go sys3, who knows) Current status, waiting on your comments, afflib folks ... signature.asc Description: Digital signature
Bug#513620: [pkg-ntp-maintainers] Bug#513620: ntp: Please check for a loopback interface
On Sat, Jan 31, 2009 at 07:46:58PM +0100, Kurt Roeckx wrote: How do you expect ntpq to connect to localhost when you didn't configure it? Note that the manpage clearly states that localhost is the default. OK maybe my bug report was not so well written. Sorry about that. If ntpd can not be contacted by ntpq, perhaps because of /etc/init.d/ntp stop then you get the following error from ntpq when it can not reach ntpd: ntpq: read: Connection refused I am familiar with that error message. On the other hand, if ntpd is up and running perfectly, but interface lo is down, such as ifdown lo, then you get the following error from ntpq when it can not reach ntpd: localhost: timed out, nothing received ***Request timed out. That's odd... It would seem more intuitive if both failures to contact ntpd errored out the same way. Why two different error messages for the same situation of ntpq cannot contact ntpd, depending on which ip interfaces happen to be up or down? And I'm pretty sure that there are alot of things that break if you do not have localhost configured. Oh, you might be surprised if it happened to you, in my semi-embedded nfs-root situation, due to a misconfiguration removing lo, all that failed was NFS statd would hang on startup with no error or log, portmap would not shutdown cleanly (although that happens late in shutdown, and who ever notices that on an embedded machine) and ntpq gave that unusual response when unable to talk to ntpd. We can agree, if you'd like, that I'll work beginning from the point that almost nothing fails without a localhost, and you can work beginning from the point that alot of things break, but that all doesn't really change anything in this particular package. It's only a wishlist bug because I agree it's not the end of the world. Anyway, thanks for your work on ntp, and have a nice day. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513619: portmap: Please check for a loopback interface
Package: portmap Version: 6.0-9 Severity: wishlist One problem that can occur with NFS / portmap is a lack of a loopback interface. If there is no loopback interface, almost everything on a typical server works except for boot up hanging at starting statd, shutdown hanging at stopping portmap, and during operation running ntpq will fail to connect to a running NTP. (obviously NTP isn't your thing, but its the only other symptom of a missing loopback that I could find) Some examples of problems relating to a lack of a loopback address: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348373 Some more detail, of possible usefulness, available in my blog post at http://vincemulhollon.blogspot.com/2009/01/debian-nfs-root-interface-configuration.html Maybe an active check would be too intrusive, perhaps something a bit more passive like grep the output of ifconfig to see if there is a Loopback and if none, then echo out an error at the start of the init.d scripts. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages portmap depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii libc6 2.7-18 GNU C Library: Shared libraries ii libwrap0 7.6.q-16 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip portmap recommends no packages. portmap suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513620: ntp: Please check for a loopback interface
Package: ntp Version: 1:4.2.4p4+dfsg-8 Severity: wishlist If you do not have a loopback interface configured then ntp will work and sync your time, but ntpq will error out and fail to connect to the running ntp server. The only other common symptom of a missing loopback that I could find was that portmap / statd blows up (assuming you even have that installed to run NFS). NFS isn't your thing, I'm just including it to show that ntpq is one of the few things that won't work without a loopback and nothing in Debian provides any error. Maybe something as simple as in the start of the init.d script, grep the output of ifconfig for a Loopback and if none found, echo some comment about ntpq will not work until you add a loopback interface. Some extra commentary at this blog post http://vincemulhollon.blogspot.com/2009/01/debian-nfs-root-interface-configuration.html Its easier than you would expect to end up with no configured loopback on a NFS-root mounted diskless workstation. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ntp depends on: ii adduser 3.110 add and remove users and groups ii libc62.7-18 GNU C Library: Shared libraries ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libedit2 2.11~20080614-1 BSD editline and history libraries ii libncurses5 5.7+20081213-1 shared libraries for terminal hand ii libssl0.9.8 0.9.8g-15 SSL shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii netbase 4.34Basic TCP/IP networking system Versions of packages ntp recommends: ii perl 5.10.0-19 Larry Wall's Practical Extraction Versions of packages ntp suggests: ii ntp-doc 1:4.2.4p4+dfsg-8 Network Time Protocol documentatio -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513623: munin-node: Munin-node will not start if /var/log/munin directory does not exist
Package: munin-node Version: 1.2.6-8 Severity: wishlist Thanks for maintaining munin. munin-node will fail to start at boot up if the directory /var/log/munin does not exist, as typically seen in a nfs-root configuration. The standard nfs-root as provided by the nfsbooted package has a file /etc/nfsbooted/fstab which adds the following line to /etc/fstab /dev/ram5 /var/log ramfs defaults,rw,auto,dev 0 0 The idea is to store logs locally for speed instead of flowing over nfs-root. But munin-node reacts poorly to its log directory /var/log/munin being deleted every boot, and will not start until the directory is manually made, and then /etc/init.d/munin-node start. There are workarounds from the direction of not logging to a fresh ramdisk every boot. But, it might be nice if munin-node were a bit less brittle about it's directory being deleted upon startup, maybe creating it again if it got deleted. For that matter, maybe munin-node could just log into /var/log, instead of /var/log/munin ? -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages munin-node depends on: ii adduser 3.110add and remove users and groups ii gawk1:3.1.5.dfsg-4.1 GNU awk, a pattern scanning and pr ii libnet-server-perl 0.97-1 An extensible, general perl server ii lsb-base3.2-20 Linux Standard Base 3.2 init scrip ii perl5.10.0-19Larry Wall's Practical Extraction ii procps 1:3.2.7-9/proc file system utilities Versions of packages munin-node recommends: pn libnet-snmp-perl none (no description available) Versions of packages munin-node suggests: ii acpi1.1-2displays information on ACPI devic ii ethtool 6+20080913-1 display or change Ethernet device pn libdbd-pg-perl none (no description available) pn liblwp-useragent-determined none (no description available) pn libnet-irc-perl none (no description available) ii libwww-perl 5.813-1 WWW client/server library for Perl ii lm-sensors 1:3.0.2-1+b2 utilities to read temperature/volt ii munin 1.2.6-8 network-wide graphing framework (g pn munin-plugins-extra none (no description available) ii mysql-client5.0.51a-21 MySQL database client (metapackage ii mysql-client-5.0 [mysql-cli 5.0.51a-21 MySQL database client binaries ii python 2.5.2-3 An interactive high-level object-o ii smartmontools 5.38-2 control and monitor storage system -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#429055: Temporary workaround
until the patch is applied and uploaded, after package installation, as the root user, run the two lines below as root to work around this bug mkdir /usr/lib/predict/default cp /usr/lib/predict/* /usr/lib/predict/default/ You will get the following error message cp: omitting directory `/usr/lib/predict/default' but thats ok it'll work anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486842: modemu: Correction to QuickStart file
Package: modemu Version: 0.0.1-10 Severity: normal Thanks for maintaining modemu as it has come in handy for me in some weird, yet fun, situations. Anyway, in the file /usr/share/doc/modemu/QuickStart Please change the line from modemu -e AT%B0=1%B1=1W -c minicom -p tty%s To modemu -e AT%B0=1%B1=1W -c minicom -p %s Otherwise on a modern system running unstable you get an error like this minicom: cannot open /dev/tty/dev/pts/5: Not a directory Comm program exited. You see, in the old days, %s would return only the pty number hence the need for a prefix like tty. But now %s returns something like /dev/pts/5, the full file name, which passes to minicom as tty/dev/pts/5 whom reinterprets devices without a leading / as begining with /dev, resulting in /dev/tty/dev/pts/5 which just isn't going to work. Not having a copy of xc I have no way to verify this, but I'm guessing that /usr/share/doc/modemu/README also needs to change from modemu -c xc -l tty%s To modemu -c xc -l %s Anyway please have a pleasant day. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages modemu depends on: ii libc6 2.7-11 GNU C Library: Shared libraries modemu recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331236: rt3.4-apache2: Please include apache2-fastcgi.conf
Package: rt3.4-apache2 Severity: important Hello, First, thank you for maintaining RT, it is appreciated. Please include etc/request-tracker3.4/apache-fastcgi.conf from rt3.4-apache into rt3.4-apache2 I think all you need to do is copy debian/conf/apache-fastcgi.conf to debian/conf/apache2-fastcgi.conf and then edit line 20 to comment it out as seen here: #FastCgiIpcDir /var/run/fastcgi If you do that, then fastcgi works great with apache2, with only one minor problem, I had manually configured my apache to look for apache-fastcgi.conf which is now named apache2-fastcgi.conf, probably worth a notice in the changelog and in /usr/share/doc/request-tracker3.4 that the file name has changed to a more logical name. I have a wishlist bug under request-tracker3.4 detailing my experiences running RT using fastcgi under apache2, which might be worth reviewing while considering this bug, it is bug 327064 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.7-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326958: syslog
Hello, Sorry for not responding sooner, I didn't get the email from the BTS. Cut and paste from bugs.debian.org: This strongly suggests to me that you are using a locally compiled/installed version of Perl and not the one shipped as part of Debian (that would be in /usr/lib/perl and /usr/share/perl). With this in mind I am not sure I am going to be able to help you very much as the problem could just as easily be in the perl as in my request-tracker3.4 package. I recommend you run request-tracker3.4 (and all Debian perl packages for that matter) with the version of perl shipped with Debian and see if that fixes your problems. If nothing else this will provide an upgrade from the 5.8.2 version you are using to the 5.8.7 which comes with testing/etch. We do depend on a version of perl (= 5.8.3) for a good reason, ignoring dependency lists is going to result in all sorts of trouble for you. History of the box is installed from stable CDroms, then upgraded to testing. The error is from liblog-dispatch-perl. Heres all my /var/log/dpkg.log lines for perl, liblog, and rt: 2005-08-09 13:33:43 install perl none 5.8.7-3 2005-09-06 15:20:08 install liblog-dispatch-perl none 2.10-1 2005-09-06 15:20:09 install request-tracker3.4 none 3.4.2-4 2005-10-02 08:37:22 upgrade request-tracker3.4 3.4.2-4 3.4.4-1 The box lives behind a firewall with no inward access only outbound thru a proxy/cache to port 80, so its unlikely it was rooted. Its a fresh testing box never used for development doesn't even have a compiler installed... Nothing in /opt etc. Which I agree makes a weird error message. I looked at: http://search.cpan.org/src/DROLSKY/Log-Dispatch-2.11/Changes And found: 2.10 Feb 11, 2004 - Fix a doc bug in Log::Dispatch::Syslog. It defaults to using a unix socket, not an inet socket. The problem in the past seemed to be RT was trying to connect via the unix socket thus I had to force it to the default inet socket, although upstream claims it was only a documentation change. Also the same version of liblog-dispatch-perl is in stable, testing, and unstable. Today I changed /etc/request-tracker3.4/RT_SiteConfig.pm back to @LogToSyslogConf = () unless (@LogToSyslogConf); restarted, and don't get the old error. However this was after I upgraded today per /var/log/dpkg.log 2005-10-02 08:37:22 upgrade request-tracker3.4 3.4.2-4 3.4.4-1 I guess file this as unreproducible.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327064: request-tracker3.4: HOWTO apache2 fastcgi
Package: request-tracker3.4 Severity: wishlist Here is a collection of notes regarding the installation of rt3.4 on apache2 using fastcgi, mysql, and testing distribution. With some editing, this might be a useful addition to the rt3.4 package for your next upload. Maybe call it apache2-fastcgi.howto.txt - apt-get install request-tracker3.4 will pull in a bunch of apache1 dependancies, no negative effects seen against my apache2 install. - Install the missing dependancies: apt-get install libapache2-mod-fastcgi libcgi-fast-perl - enable the fastcgi module in /etc/apache2/mods-enabled cd /etc/apache2/mods-enabled ln -s /etc/apache2/mods-available/fastcgi* . - In /etc/request-tracker3.4/apache-fastcgi.conf comment out this line #FastCgiIpcDir /var/run/fastcgi - chmod a+r /etc/request-tracker3.4/RT_SiteConfig.pm (Would recomment further contemplation of this, if done on an externally accessible production internet server instead of a intranet or test server) Note this lets anyone who and log in, read the mysql uname/pword, which may or may not be a problem depending on individual situation. - Add file /etc/apache2/conf.d/rt # Request Tracker /etc/apache2/conf.d/rt Include /etc/request-tracker3.4/apache-fastcgi.conf RewriteRule ^/rt$ /rt/ RewriteRule ^/rt/(.*)$ /usr/share/request-tracker3.4/html/$1 # - Install mysql, read /usr/share/doc/request-tracker3.4/INSTALL.Debian.gz - To fix the strange syslog bug, add these two lines to /etc/request-tracker3.4/RT_SiteConfig.pm # Mod for recent Debian syslog @LogToSyslogConf = ( socket = 'inet' ) unless (@LogToSyslogConf); - Restart apache2 and it should work! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326958: request-tracker3.4: no connection to syslog available at /opt/machine/perl/lib/site_perl/5.8.2/Log/Dispatch/Syslog.pm line 77
Package: request-tracker3.4 Severity: normal Hello, First, thank you for maintaining RT. On my recently updated testing box I get the following error at my initial login. I get the login page, then type in the root password, and it fails with this error, when RT is trying to log my successful login attempt: no connection to syslog available at /opt/machine/perl/lib/site_perl/5.8.2/Log/Dispatch/Syslog.pm line 77 I checked out the RT Wiki at: http://wiki.bestpractical.com/index.cgi?NoConnectionToSyslog And all I needed to do was add the following line to /etc/request-tracker3.4/RT_SiteConfig.pm @LogToSyslogConf = ( socket = 'inet' ) unless (@LogToSyslogConf); From what I see on the RT wiki, they are not certain where the bug is located, if it's theirs or ours. Perhaps for now, you could modify the docs to mention this, and add the provided line, commented out, in RT_SiteConfig.pm Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311404: O: ts10 -- Emulators for various old computers
Package: wnpp Severity: normal I intend to orphan the ts10 package. The package description is: This package contains emulators for the following computers: TI-99/4 DEC PDP-10 DEC PDP-11 DEC VAX It is considered alpha code but is highly usable. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.7-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
