August 2020 - openSUSE Users - openSUSE Mailing Lists

[opensuse] after upgrade, ssh no longer works
by ken 10 Aug '20

10 Aug '20

After upgrading yesterday (VERSION="20200803"), I can no longer ssh into a local machine. I'm assured that the problem is not with the remote machine: not only have I not changed anything on it, but also I can still ssh into it from a third machine as I always have. Here's an attempt from the newly updatetd machine: $ ssh -vv hostd OpenSSH_8.3p1, OpenSSL 1.1.1g 21 Apr 2020 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * debug2: resolving "hostd" port 22 debug2: ssh_connect_direct debug1: Connecting to hostd [192.168.0.26] port 22. debug1: Connection established. debug1: identity file /home/zl1/.ssh/id_rsa type 0 debug1: identity file /home/zl1/.ssh/id_rsa-cert type -1 debug1: identity file /home/zl1/.ssh/id_dsa type -1 debug1: identity file /home/zl1/.ssh/id_dsa-cert type -1 debug1: identity file /home/zl1/.ssh/id_ecdsa type -1 debug1: identity file /home/zl1/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/zl1/.ssh/id_ecdsa_sk type -1 debug1: identity file /home/zl1/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/zl1/.ssh/id_ed25519 type -1 debug1: identity file /home/zl1/.ssh/id_ed25519-cert type -1 debug1: identity file /home/zl1/.ssh/id_ed25519_sk type -1 debug1: identity file /home/zl1/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/zl1/.ssh/id_xmss type -1 debug1: identity file /home/zl1/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.3 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH_2*,OpenSSH_3*,OpenSSH_4* compat 0x00000002 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to hostd:22 as 'zl1' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib(a)openssh.com,zlib debug2: compression stoc: none,zlib(a)openssh.com,zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: host key algorithms: ssh-rsa,ssh-dss debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc(a)lysator.liu.se debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc(a)lysator.liu.se debug2: MACs ctos: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160(a)openssh.com,hmac-sha1-96,hmac-md5-96 debug2: MACs stoc: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160(a)openssh.com,hmac-sha1-96,hmac-md5-96 debug2: compression ctos: none,zlib(a)openssh.com debug2: compression stoc: none,zlib(a)openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: (no match) Unable to negotiate with 192.168.1.44 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 Running "zypper up ssh" said "Nothing to do". I also renamed my ~/.ssh directory on the upgraded machine and replaced it with a copy of the entire ~/.ssh directory from the third (working) machine on my lan. Still no joy. Can anyone tell me what's going on? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 6

[opensuse] how to change back to the previous "Switch Applications" functionality
by ken 10 Aug '20

10 Aug '20

The new way of switching applications (normally with Alt-Tab) is a lot more work and more cumbersome than the previous way. Is there any way to switch back to the previous functionality? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

10 26

[opensuse] A problem with the smartd daemon.
by Carlos E. R. 09 Aug '20

09 Aug '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get these repeated warnings in the log of my home server: <3.2> 2020-08-01T17:17:14.068115+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], failed to read SMART Attribute Data <3.2> 2020-08-01T18:17:14.247482+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], failed to read SMART Attribute Data But the thing is, smartctl can read that disk just fine: Isengard:~ # smartctl -i /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0\:0 smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.12.14-lp151.28.52-default] (SUSE RPM) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: WDC HGST Ultrastar He10 Device Model: WDC WD80EZAZ-11TDBA0 Serial Number: 2TKST2SD LU WWN Device Id: 5 000cca 26af51579 Firmware Version: 83.H0A83 User Capacity: 8,001,563,222,016 bytes [8.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5400 rpm Form Factor: 3.5 inches Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4 SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sat Aug 1 13:51:20 2020 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled Isengard:~ # Isengard:~ # smartctl -A /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0\:0 smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.12.14-lp151.28.52-default] (SUSE RPM) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0004 128 128 054 Old_age Offline - 116 ... Isengard:~ # smartctl --test=short /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0\:0 smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.12.14-lp151.28.52-default] (SUSE RPM) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Short self-test routine immediately in off-line mode". Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful. Testing has begun. Please wait 2 minutes for test to complete. Test will complete after Sat Aug 1 20:30:49 2020 CEST Use smartctl -X to abort test. Isengard:~ # Looking at the /var/log/messages file, it gets weirder: <3.6> 2020-08-01T15:47:03.217524+02:00 Isengard smartd 3543 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], state written to /var/lib/smartmontools/smartd.WDC_WD80EZAZ_11TDBA0-2TKST2SD.ata.state <3.6> 2020-08-01T15:47:04.105688+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], opened <3.6> 2020-08-01T15:47:04.106285+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], WDC WD80EZAZ-11TDBA0, S/N:2TKST2SD, WWN:5-000cca-26af51579, FW:83.H0A83, 8.00 TB <3.6> 2020-08-01T15:47:04.119302+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], found in smartd database: WDC HGST Ultrastar He10 <3.6> 2020-08-01T15:47:04.135383+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], enabled SMART Attribute Autosave. <3.6> 2020-08-01T15:47:04.142911+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], is SMART capable. Adding to "monitor" list. <3.6> 2020-08-01T15:47:04.144358+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], state read from /var/lib/smartmontools/smartd.WDC_WD80EZAZ_11TDBA0-2TKST2SD.ata.state <3.6> 2020-08-01T15:47:04.717689+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], state written to /var/lib/smartmontools/smartd.WDC_WD80EZAZ_11TDBA0-2TKST2SD.ata.state <3.6> 2020-08-01T16:17:12.489203+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], not capable of SMART self-check <3.2> 2020-08-01T16:17:14.439038+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], failed to read SMART Attribute Data <3.6> 2020-08-01T16:17:16.388831+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], Read SMART Self Test Log Failed <3.6> 2020-08-01T16:47:04.708009+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 130 to 132 <3.6> 2020-08-01T17:17:12.118117+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], not capable of SMART self-check <3.2> 2020-08-01T17:17:14.068115+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], failed to read SMART Attribute Data <3.6> 2020-08-01T18:17:12.297698+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], not capable of SMART self-check <3.2> 2020-08-01T18:17:14.247482+02:00 Isengard smartd 5945 - - Device: /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 [SAT], failed to read SMART Attribute Data Isengard:~ # It did read the temperature change, but it claims the other errors, which are false. The configuration is: Isengard:~ # cat /etc/smartd.conf | egrep -v "^[[:space:]]*$|^#" /dev/sda -a -S on -T permissive -s (S/../.././02|L/../../6/03) -m root(a)telcontar.valinor /dev/disk/by-id/wwn-0x5000c50075a83eaf -d removable -a -o on -S on -s (S/../.././02|L/../../6/03) -m root(a)telcontar.valinor /dev/disk/by-id/wwn-0x5000c5009399305f -d removable -a -o on -S on -s (S/../.././02|L/../../6/03) -m root(a)telcontar.valinor /dev/disk/by-id/wwn-0x5000c500c4beb480 -d removable -a -o on -S on -s (S/../.././02|L/../../6/03) -m root(a)telcontar.valinor /dev/disk/by-id/usb-WD_My_Book_25EE_32544B5354325344-0:0 -d removable -a -S on -s (S/../.././02|L/../../6/03) /dev/disk/by-id/usb-WD_My_Book_25EE_37484B53554B424A-0:0 -d removable -a -S on -s (S/../.././02|L/../../6/03) Isengard:~ # Ideas? - -- Cheers Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXyW2oxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVALoAniU1xYdaGy+1QAPCRquZ cvXKko/pAKCW0QUrf2rCELri0rf/VJawmzkSnw== =8hOP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 11

[opensuse] download.opensuse.org html listing format - get rid of horizontal lines...
by David C. Rankin 09 Aug '20

09 Aug '20

All, Since someone changed the basic listing format from download.opensuse.org/repositories to some unwanted html format, the biggest problem is the damn horizontal lines drawn between every directory and they are drawn in a bright-white over a dark background -- it's like looking into a floodlight trying to pick out details behind it. Take a look at: https://download.opensuse.org/repositories/X11:/ Where I see: https://paste.opensuse.org/61684564 It is enough to drive you blind. Can we at least remove the horizontal lines? I could live with cyan folder names on a dark background if there wasn't a bright white line in between every folder. Personally, I'd prefer the raw folder listing that reduces the bandwidth by 500%, but I understand it's hard to gore somebody's new ox. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 5

[opensuse] How to turn OFF new html-ized directory listings at http://download.opensuse.org/source/distribution/leap/
by David C. Rankin 08 Aug '20

08 Aug '20

All, Just going through source listings at http://download.opensuse.org/source/distribution/leap/ there is some kind of new "Pretty Print" html-ized format being used that underlines the entire row containing the srpm instead of the normal raw directory listing that only underlines the package. This (1) doubles the height of the listing you have to scroll and (2) makes scanning the listing awkward. Is there some way, or switch, that will revert to the simple listing? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

8 16

[opensuse] [SOLVED] Leap 15.2 and VLC - missing libs - libavcodec57(unrestricted)
by Andrei Verovski 08 Aug '20

08 Aug '20

Hi, Installing VLC from official VideoLAN.org repository throws these error: Problem: nothing provides libavcodec57(unrestricted) needed by vlc-codecs-3.0.11-lp152.333.3.x86_64 Solution 1: do not install vlc-codecs-3.0.11-lp152.333.3.x86_64 Solution 2: break vlc-codecs-3.0.11-lp152.333.3.x86_64 by ignoring some of its dependencies Solution is to add Packman repo which have all necessary libs. So this page need to be somehow updated (have no admin contacts). https://www.videolan.org/vlc/download-suse.html -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 1

[opensuse] Convert from classic to transactional server?
by seroton10＠gmail.com 08 Aug '20

08 Aug '20

Hi, When installing openSUSE (any flavour), the installer offers a choice between the "server" and "transactional server" roles, among others. If I choose to install a "server" system, is there a (supported) procedure by which I can later convert it into a "transactional server"? I tried to do this conversion on a test system running openSUSE Leap 15.2, as follows: * run "zypper install patterns-base-transactional_base" * edit /etc/fstab to make root read-only * reboot This appears to work: The system self-updates and reboots when needed, /etc has been turned into an overlay filesystem, and zypper up tells me to use the transaction-update tool. However, one of the packages installed during the conversion is "read- only-root-fs", and its description contains a rather stern warning: Files, scripts and directories to run the system with a read-only root filesystem with /etc writeable via overlayfs. This package should never be installed in an already running system! It should only be selected by a system role for a read-only root filesystem with transactional updates. The package will create / modify entries for mounting /etc and /var. Those entries are used by dracut to mount the overlay file systems during the early boot phase. After reading this, I ask myself, was it just dumb luck that the test system wasn't destroyed during the conversion? Any clarification on this would be much appreciated. Regards, Olav -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 3

[opensuse] Why do we reboot after a systemd upgrade instead of --system daemon-reexec?
by David C. Rankin 06 Aug '20

06 Aug '20

General question, On 15.2 today, updates included systemd, ghostscript and a few other peripheral libraries, but nothing other than systemd would have conceivably called for a reboot, but yet zypper up said a reboot was required. Question, why when we update systemd do we call for a reboot instead of executing a --system daemon-reexec in the post-install part of the update? E.g. systemctl --system daemon-reexec That itself will reload system and any/all new service files. More a curiosity than a problem. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 11

[opensuse] gcc 8 on Tumbleweed
by Roger Oberholtzer 06 Aug '20

06 Aug '20

I am using the NVIDIA NVCC GPU /CUDA compiler on Tumbleweed. The package I am building (darknet) seems to work best with NVCC 10.2. So I have been using that on Tumbleweed. I am setting up a new Tumbleweed system, and I see that gcc-8 (64-bit) is no longer available. I see gcc-7 and gcc-9. But no gcc-8. If it has been removed, is it perhaps still possible to find it for Tumbleweed? I did a search on openSUSE downloads, and it only had some Debian release. Nothing for openSUSE. I tried other GCC releases witn NVCC, but it complains that they are unsupported versions. It wants gcc-8. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 6

[opensuse] Portkocking problem
by Marc Chamberlin 06 Aug '20

06 Aug '20

Hello - I am experiencing a problem with port knocking and am in need of some guidance from someone with a deeper understanding of the Linux/OpenSuSE architecture than I have. I have a computer with 2 NIC cards defined as eth0 and eth1. I am running 2 knockd daemons using nearly identical configuration files that define the knock sequences needed to open a port. The IP addresses for each card are on the same internal private subnet and assigned by a DHCPD server. When I send a knock sequence from my laptop to this system on it's eth0 interface all works fine. But when I send the same knock sequence to the eth1 interface it generally fails, although every once in awhile, as I am trying to figure out what is going on, it will work one time and then again fails on subsequent tests. I don't know what I am doing that causes these occasional successes. I have tried bringing down and back up the eth1 interface with ifup and ifdown, and tried restarting the firewalld, network, and knockd services. I have also tried putting both interfaces on the same (INTERNAL) zone (not what I really want to do, but this eliminates the possibility that placing each interface in separate zones could be causing problems.) I fired up wireshark on my target computer to monitor the eth1 interface (and the eth0 interface to see if there were any differences that might give me a clue) and wireshark does indeed show the arrival of the knock packets coming from my laptop, on both interfaces. So I know that I am sending the knocks OK and that they are indeed arriving on the appropriate interfaces. So I next inserted the following rule into the head of the INPUT chain of the iptables to monitor what it is seeing - *iptables -w -I INPUT 1 -s 192.168.10.10 -j LOG; tail -n-0 -f /var/log/messages|stdbuf -o0 grep 192.168.10.10* (192.168.10.10 is the IP address of my laptop) and while this does show the knocks coming in on eth0, it fails to show any knocks coming in on eth1 (except occasionally as I mentioned above). Does this command look correct? In particular I am not really sure where the LOG chain will send its output, I am guessing it is to the messages log file. (I have turned back on logging to the messages log file since I prefer using text files rather than the journal log which I find is too difficult to work with) I imagine that wireshark is directly monitoring eth1 by making low level calls to the eth1 driver and I would have expected iptables to be doing the same, but apparently not. So what lies between the low level driver for eth1 that wireshark is apparently using, and the beginning of the iptables chain that is blocking these port knock packets from reaching the iptables chains? Anyone with ideas? As always much appreciated and thanks in advance for taking the time to help me out! Marc.... -- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 14