users November 2019

users@lists.fedoraproject.org

97 participants
121 discussions

gnome3: external monitor, builtin still primary after lid-close
by Gabriel L. Somlo 29 Nov '19

29 Nov '19

I test-drove a vanilla install of F30 Workstation, and observed the following (correct) behavior: - without an external display, the laptop goes to sleep when the lid is closed - with the external display connected, the built-in screen becomes unavailable when the lid is closed, and the external screen becomes primary (the toolbar at the top moves there, and so do all the windows from the primary screen I then did a custom kickstart install, with a bunchof stuff *including* @gnome-desktop, which works fine overall, except: - when the lid is closed while an external display is connected, the built-in screen *remains* active (and primary, unless I explicitly make the external one primary). Since it's still marked as active/available, sometimes applications (e.g. firefox) end up sending popup boxes there, where I can't see them (since it's closed). I could not find which setting or package causes the difference in behavior between correct and incorrect, but I'd like to keep my custom kickstart installation if at all possible. Any idea how I could explicitly configure my gnome desktop environment to behave correctly w.r.t. extrenal monitor and lid-close effect on the built-in screen? Thanks much, --Gabriel

1 0

Fedora 32 Firefox and DNS over HTTPS
by Robert Moskowitz 29 Nov '19

29 Nov '19

In the upcoming Fedora 32, is Firefox defaulting to DNS over HTTPS (RFC 8484)? BTW, I am currently on F30 and will skip to F32 when it ships. If you want a high-level discuss on DNS over TLS or over HTTPS see: https://spectrum.ieee.org/tech-talk/telecom/security/the-fight-over-encrypt… One thing this article misses is if your company DNS server has an internal view for internal resources, defaulting to some outside DNS server breaks this. Or at least makes directing things the right way is hard. So what is happening with Firefox in F32? Thanks

6 6

sshd on F31 : strange problem with login with keys's
by Jouk Jansen 29 Nov '19

29 Nov '19

Hi All, I'm trying to setup an ssh-server on F31 which logs a user in without a password, but with a key-exchange. I generated all the keys and placed them in the right locations. It still asks for the password. Than comes the strange : I stoped the service by "systemctl stop sshd" and did run "as root" /usr/sbin/sshd. And than it just worked. (tried to stop and start with systemctl again made the passwordless login fail again) Question : why does is work with just running "/usr/sbin/sshd" but not with "systemctl start sshd" ? regards Jouk Pax, vel iniusta, utilior est quam iustissimum bellum. (free after Marcus Tullius Cicero (106 b.Chr.-46 b.Chr.) Epistularum ad Atticum 7.1.4.3) Touch not the cat bot a glove >------------------------------------------------------------------------------< Jouk Jansen joukj(a)hrem.nano.tudelft.nl Technische Universiteit Delft tttttttttt uu uu ddddddd Kavli Institute of Nanoscience tttttttttt uu uu dd dd Nationaal centrum voor HREM tt uu uu dd dd Lorentzweg 1 tt uu uu dd dd 2628 CJ Delft tt uu uu dd dd Nederland tt uu uu dd dd tel. 31-15-2782272 tt uuuuuuu ddddddd >------------------------------------------------------------------------------<

6 6

Speaking of efi boot...
by Tom Horsley 28 Nov '19

28 Nov '19

I have developed a procedure for installing a new fedora that insures anaconda cannot possibly screw up my disks: I install in a virtual machine, guestmount the virtual image then rsync the new fedora to the real partition and edit grub and fstab parameters. I don't yet know if the new computer I'm building supports old fashioned MSDOS booting, or if I'll finally be forced to go with EFI. I'm wondering if it is remotely possible to do the same sort of install with EFI booting. I assume I'd need the qemu EFI bios so the virtual machine is set up for EFI booting. Would efibootmgr be able to fix things after the copy? Anyone ever done this?

2 1

Re: (fedora) Re: sshd on F31 : strange problem with login with keys's
by Jouk Jansen 28 Nov '19

28 Nov '19

Ed Greshko wrote on 28-NOV-2019 13:46:10.58 >On 2019-11-28 20:28, Ed Greshko wrote: >> If you're suggesting this to be a permission issue on authorized_keys wouldn't it be a good >> idea to request the output of "ls -Z ~/.ssh"? >Oh, as well as "ls -Zd ~/.ssh"? vleegert-jj ) ls -Z .ssh system_u:object_r:default_t:s0 authorized_keys system_u:object_r:default_t:s0 config system_u:object_r:default_t:s0 id_rsa.jacobjansen system_u:object_r:default_t:s0 id_rsa.jacobjansen.pub system_u:object_r:default_t:s0 known_hosts system_u:object_r:default_t:s0 known_hosts~ system_u:object_r:default_t:s0 result.pub vleegert-jj ) ls -Zd .ssh system_u:object_r:default_t:s0 .ssh vleegert-jj ) Pax, vel iniusta, utilior est quam iustissimum bellum. (free after Marcus Tullius Cicero (106 b.Chr.-46 b.Chr.) Epistularum ad Atticum 7.1.4.3) Touch not the cat bot a glove >------------------------------------------------------------------------------< Jouk Jansen joukj(a)hrem.nano.tudelft.nl Technische Universiteit Delft tttttttttt uu uu ddddddd Kavli Institute of Nanoscience tttttttttt uu uu dd dd Nationaal centrum voor HREM tt uu uu dd dd Lorentzweg 1 tt uu uu dd dd 2628 CJ Delft tt uu uu dd dd Nederland tt uu uu dd dd tel. 31-15-2782272 tt uuuuuuu ddddddd >------------------------------------------------------------------------------<

2 1

Calendar display -
by Bob Goodwin 27 Nov '19

27 Nov '19

. I need some help with the tkremind calendar display in Fedora-31. Perhaps someone else is familiar with it and can offer a solution or an alternative to tkremind. All I need is a calendar format similar to a monthly paper calendar that I can list appointments on some days, Sometimes a medical appointment might be a year in the future. I don't want pop up displays for those days, just something that looks like an old paper calendar that might have hung on the wall. I sent the following request to the "remind" mail list and got no response so now here. I've been using this with Fedora over a number of releases and it has always worked through Fedora-29, on several different computers. Presently I an seeing this problem on two Fedora-31 xfce workstations. It displays as I want it for a fraction of a second and then reverts to black on white which does not work for me. I need to change the color of the month calendar display to present a white foreground on a black background to accommodate my vision problems. I have done this for some time with the following /home/bobg/.xresources: ! Reloads .Xresources file ! $ xrdb ~/.Xresources ! ! Shows contents of all properties ! $ xrdb -query ! ! Font settings extras Xft.dpi: 120 Xft.antialias: true Xft.hinting: true Xft.rgba: rgb Xft.autohint: false Xft.hintstyle: hintfull Xft.lcdfilter: lcdfilter ! ! /usr/local/bin/tkremind cooperation tkremind*Background: #000000 tkremind*Foreground: #ffffff tkremind*activeBackground: #000000 tkremind*activeForeground: #ffffff tkremind*highlightBackground: #00ff00 tkremind*selectBackground: #000000 tkremind*selectForeground: #ffffff ! Note: I did not create this it was suggested to me by Poma, <pomidorabelisima(a)gmail.com> in response to a request for help on the Fedora list. This has done what I need until Fedora-31, now the white text on a black background calendar comes on for a few milliseconds and reverts to black text on a white background. Can this be fixed or perhaps there is a better method for doing it? Any help in this will be appreciated, Bob -- Bob Goodwin - Zuni, Virginia, Fedora Linux-31 XFCE

2 5

openssl : 1.0.2k-fips vs. 1.1.1d
by Adrian Sevcenco 27 Nov '19

27 Nov '19

Does anyone have a pointer or idea what changed in terms of ciphers or algos or curves between the two versions? i have 2 pierces of software : the server which is java based and the client (python based, websockets) on centos7 1.0.2.k-fips i can connect to the localhost but in fedora{30,31} i have an SSLV3_ALERT_CERTIFICATE_UNKNOWN error Any idea whats is going on? Thanks a lot! Adrian

2 2

Re: (fedora) Re: sshd on F31 : strange problem with login with keys's
by Jouk Jansen 27 Nov '19

27 Nov '19

Tom Horsley wrote on 26-NOV-2019 19:05:50.24 >Try running the ssh command which is attempting to >login with the -v -v -v options, then you can see what it Does not learn me much (I added the log below). They are different from line 99 when a 1 or 0 is returned which enables/disables the key-login apparently. >is trying and what didn't work. >If it is an old enough system it may not share any >ciphers with the new f31 system as they have disabled >a lot of old ciphers by default. This would be strange since I put all the needed cyphers in /etc/ssh/sshd_config. And why would it work for running the command manually and not for the one started with systemctl? Regards Jouk ========= log with starting manually (connects OK ) tango-jj) ssh -v -v -v vleegert debug(27-NOV-2019 08:11:00.58): Ssh2/SSH2.C:1896: CRTL version (SYS$SHARE:DECC$S HR.EXE ident) is ELF debug(27-NOV-2019 08:11:00.60): SshAppCommon/SSHAPPCOMMON.C:313: Allocating glob al SshRegex context. debug(27-NOV-2019 08:11:00.61): SshConfig/SSHCONFIG.C:3482: Metaconfig parsing s topped at line 4. debug(27-NOV-2019 08:11:00.61): SshConfig/SSHCONFIG.C:890: Setting variable 'Ver boseMode' to 'FALSE'. debug(27-NOV-2019 08:11:00.61): SshConfig/SSHCONFIG.C:3390: Unable to open ssh2/ ssh2_config debug(27-NOV-2019 08:11:00.62): Connecting to vleegert, port 22... (SOCKS not us ed) debug(27-NOV-2019 08:11:00.62): Ssh2/SSH2.C:2881: Entering event loop. debug(27-NOV-2019 08:11:00.64): Ssh2Client/SSHCLIENT.C:1655: Creating transport protocol. debug(27-NOV-2019 08:11:00.64): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "publickey" to usable methods. debug(27-NOV-2019 08:11:00.64): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "password" to usable methods. debug(27-NOV-2019 08:11:00.64): Ssh2Client/SSHCLIENT.C:1696: Creating userauth p rotocol. debug(27-NOV-2019 08:11:00.64): client supports 2 auth methods: 'publickey,passw ord' debug(27-NOV-2019 08:11:00.64): SshUnixTcp/SSHUNIXTCP.C:1758: using local hostna me tango.nano.tudelft.nl debug(27-NOV-2019 08:11:00.64): Ssh2Common/SSHCOMMON.C:541: local ip = 131.180.1 21.84, local port = 57056 debug(27-NOV-2019 08:11:00.64): Ssh2Common/SSHCOMMON.C:543: remote ip = 131.180. 116.49, remote port = 22 debug(27-NOV-2019 08:11:00.64): SshConnection/SSHCONN.C:2584: Wrapping... debug(27-NOV-2019 08:11:00.64): SshReadLine/SSHREADLINE.C:3662: Initializing Rea dLine... debug(27-NOV-2019 08:11:00.66): Remote version: SSH-2.0-OpenSSH_8.1 debug(27-NOV-2019 08:11:00.66): OpenSSH: Major: 8 Minor: 1 Revision: 0 debug(27-NOV-2019 08:11:00.66): Ssh2Transport/TRCOMMON.C:1857: All versions of O penSSH handle kex guesses incorrectly. debug(27-NOV-2019 08:11:00.66): Ssh2Transport/TRCOMMON.C:1935: Using Client orde r for common key exchange algorithms. debug(27-NOV-2019 08:11:00.66): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:11:00.66): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 20 to connection debug(27-NOV-2019 08:11:00.66): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=2 0 debug(27-NOV-2019 08:11:00.66): Ssh2Transport/TRCOMMON.C:2394: lang s to c: `', lang c to s: `' debug(27-NOV-2019 08:11:00.66): Ssh2Transport/TRCOMMON.C:2459: c_to_s: cipher ae s128-cbc, mac hmac-sha1, compression none debug(27-NOV-2019 08:11:00.66): Ssh2Transport/TRCOMMON.C:2462: s_to_c: cipher ae s128-cbc, mac hmac-sha1, compression none debug(27-NOV-2019 08:11:00.67): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:11:00.67): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 30 to connection debug(27-NOV-2019 08:11:00.68): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=3 1 debug(27-NOV-2019 08:11:00.69): Remote host key found from database. debug(27-NOV-2019 08:11:00.70): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:11:00.70): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 21 to connection debug(27-NOV-2019 08:11:00.70): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:11:00.70): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 5 to connection debug(27-NOV-2019 08:11:00.70): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=2 1 debug(27-NOV-2019 08:11:00.70): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=6 debug(27-NOV-2019 08:11:00.70): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:11:00.70): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 50 to connection debug(27-NOV-2019 08:11:00.71): Ssh2Common/SSHCOMMON.C:342: Received SSH_CROSS_S TARTUP packet from connection protocol. debug(27-NOV-2019 08:11:00.71): Ssh2Common/SSHCOMMON.C:392: Received SSH_CROSS_A LGORITHMS packet from connection protocol. debug(27-NOV-2019 08:11:00.71): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=5 1 debug(27-NOV-2019 08:11:00.71): server offers auth methods 'publickey,gssapi-key ex,gssapi-with-mic,password'. debug(27-NOV-2019 08:11:00.72): Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:1677: adding keyfile "/SYS$SYSDEVICE/JOUKJ/COM/ssh2/ID_DSA_2048_A" to candidates debug(27-NOV-2019 08:11:00.72): Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:1677: adding keyfile "/SYS$SYSDEVICE/JOUKJ/COM/ssh2/ID_RSA_2048_A" to candidates debug(27-NOV-2019 08:11:00.72): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:11:00.72): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 50 to connection debug(27-NOV-2019 08:11:00.73): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=5 1 debug(27-NOV-2019 08:11:00.73): server offers auth methods 'publickey,gssapi-key ex,gssapi-with-mic,password'. debug(27-NOV-2019 08:11:00.73): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:11:00.73): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 50 to connection debug(27-NOV-2019 08:11:00.74): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=6 0 debug(27-NOV-2019 08:11:00.74): Constructing and sending signature in publickey authentication. debug(27-NOV-2019 08:11:00.74): Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:869: ssh_cli ent_auth_pubkey_send_signature: reading /SYS$SYSDEVICE/JOUKJ/COM/ssh2/ID_RSA_204 8_A debug(27-NOV-2019 08:11:00.81): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:11:00.81): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 50 to connection debug(27-NOV-2019 08:11:00.85): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=5 2 debug(27-NOV-2019 08:11:00.86): Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:1915: Public key authentication was successful. ======================== ========= log with starting with systemctl (connects not without password ) tango-jj) ssh -v -v -v vleegert debug(27-NOV-2019 08:10:22.77): Ssh2/SSH2.C:1896: CRTL version (SYS$SHARE:DECC$S HR.EXE ident) is ELF debug(27-NOV-2019 08:10:22.79): SshAppCommon/SSHAPPCOMMON.C:313: Allocating glob al SshRegex context. debug(27-NOV-2019 08:10:22.80): SshConfig/SSHCONFIG.C:3482: Metaconfig parsing s topped at line 4. debug(27-NOV-2019 08:10:22.80): SshConfig/SSHCONFIG.C:890: Setting variable 'Ver boseMode' to 'FALSE'. debug(27-NOV-2019 08:10:22.80): SshConfig/SSHCONFIG.C:3390: Unable to open ssh2/ ssh2_config debug(27-NOV-2019 08:10:22.81): Connecting to vleegert, port 22... (SOCKS not us ed) debug(27-NOV-2019 08:10:22.81): Ssh2/SSH2.C:2881: Entering event loop. debug(27-NOV-2019 08:10:22.83): Ssh2Client/SSHCLIENT.C:1655: Creating transport protocol. debug(27-NOV-2019 08:10:22.83): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "publickey" to usable methods. debug(27-NOV-2019 08:10:22.83): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "password" to usable methods. debug(27-NOV-2019 08:10:22.83): Ssh2Client/SSHCLIENT.C:1696: Creating userauth p rotocol. debug(27-NOV-2019 08:10:22.83): client supports 2 auth methods: 'publickey,passw ord' debug(27-NOV-2019 08:10:22.83): SshUnixTcp/SSHUNIXTCP.C:1758: using local hostna me tango.nano.tudelft.nl debug(27-NOV-2019 08:10:22.83): Ssh2Common/SSHCOMMON.C:541: local ip = 131.180.1 21.84, local port = 57055 debug(27-NOV-2019 08:10:22.83): Ssh2Common/SSHCOMMON.C:543: remote ip = 131.180. 116.49, remote port = 22 debug(27-NOV-2019 08:10:22.83): SshConnection/SSHCONN.C:2584: Wrapping... debug(27-NOV-2019 08:10:22.83): SshReadLine/SSHREADLINE.C:3662: Initializing Rea dLine... debug(27-NOV-2019 08:10:22.85): Remote version: SSH-2.0-OpenSSH_8.1 debug(27-NOV-2019 08:10:22.85): OpenSSH: Major: 8 Minor: 1 Revision: 0 debug(27-NOV-2019 08:10:22.85): Ssh2Transport/TRCOMMON.C:1857: All versions of O penSSH handle kex guesses incorrectly. debug(27-NOV-2019 08:10:22.85): Ssh2Transport/TRCOMMON.C:1935: Using Client orde r for common key exchange algorithms. debug(27-NOV-2019 08:10:22.85): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:10:22.85): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 20 to connection debug(27-NOV-2019 08:10:22.85): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=2 0 debug(27-NOV-2019 08:10:22.85): Ssh2Transport/TRCOMMON.C:2394: lang s to c: `', lang c to s: `' debug(27-NOV-2019 08:10:22.85): Ssh2Transport/TRCOMMON.C:2459: c_to_s: cipher ae s128-cbc, mac hmac-sha1, compression none debug(27-NOV-2019 08:10:22.85): Ssh2Transport/TRCOMMON.C:2462: s_to_c: cipher ae s128-cbc, mac hmac-sha1, compression none debug(27-NOV-2019 08:10:22.86): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:10:22.86): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 30 to connection debug(27-NOV-2019 08:10:22.87): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=3 1 debug(27-NOV-2019 08:10:22.88): Remote host key found from database. debug(27-NOV-2019 08:10:22.89): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:10:22.89): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 21 to connection debug(27-NOV-2019 08:10:22.89): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:10:22.89): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 5 to connection debug(27-NOV-2019 08:10:22.89): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=2 1 debug(27-NOV-2019 08:10:22.89): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=6 debug(27-NOV-2019 08:10:22.89): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:10:22.89): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 50 to connection debug(27-NOV-2019 08:10:22.89): Ssh2Common/SSHCOMMON.C:342: Received SSH_CROSS_S TARTUP packet from connection protocol. debug(27-NOV-2019 08:10:22.89): Ssh2Common/SSHCOMMON.C:392: Received SSH_CROSS_A LGORITHMS packet from connection protocol. debug(27-NOV-2019 08:10:22.90): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=5 1 debug(27-NOV-2019 08:10:22.90): server offers auth methods 'publickey,gssapi-key ex,gssapi-with-mic,password'. debug(27-NOV-2019 08:10:22.90): Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:1677: adding keyfile "/SYS$SYSDEVICE/JOUKJ/COM/ssh2/ID_DSA_2048_A" to candidates debug(27-NOV-2019 08:10:22.91): Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:1677: adding keyfile "/SYS$SYSDEVICE/JOUKJ/COM/ssh2/ID_RSA_2048_A" to candidates debug(27-NOV-2019 08:10:22.91): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:10:22.91): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 50 to connection debug(27-NOV-2019 08:10:22.92): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=5 1 debug(27-NOV-2019 08:10:22.92): server offers auth methods 'publickey,gssapi-key ex,gssapi-with-mic,password'. debug(27-NOV-2019 08:10:22.92): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:10:22.92): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 50 to connection debug(27-NOV-2019 08:10:22.93): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=5 1 debug(27-NOV-2019 08:10:22.93): server offers auth methods 'publickey,gssapi-key ex,gssapi-with-mic,password'. debug(27-NOV-2019 08:10:22.93): Ssh2AuthClient/SSHAUTHC.C:378: Method 'publickey ' disabled. debug(27-NOV-2019 08:10:22.93): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 2 to connection debug(27-NOV-2019 08:10:22.93): Ssh2Transport/TRCOMMON.C:1139: Sending packet wi th type 50 to connection debug(27-NOV-2019 08:10:22.94): Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=5 1 debug(27-NOV-2019 08:10:22.94): server offers auth methods 'publickey,gssapi-key ex,gssapi-with-mic,password'. debug(27-NOV-2019 08:10:22.94): Ssh2AuthPasswdClient/AUTHC-PASSWD.C:280: Startin joukj's password: . Cancel ========== Pax, vel iniusta, utilior est quam iustissimum bellum. (free after Marcus Tullius Cicero (106 b.Chr.-46 b.Chr.) Epistularum ad Atticum 7.1.4.3) Touch not the cat bot a glove >------------------------------------------------------------------------------< Jouk Jansen joukj(a)hrem.nano.tudelft.nl Technische Universiteit Delft tttttttttt uu uu ddddddd Kavli Institute of Nanoscience tttttttttt uu uu dd dd Nationaal centrum voor HREM tt uu uu dd dd Lorentzweg 1 tt uu uu dd dd 2628 CJ Delft tt uu uu dd dd Nederland tt uu uu dd dd tel. 31-15-2782272 tt uuuuuuu ddddddd >------------------------------------------------------------------------------<

1 0

f31 : pkgconfig.exists( 'uuid-dev' ) false but installed
by Adrian Sevcenco 27 Nov '19

27 Nov '19

Hi! I have a strange problem in fedora 31 with the fact that even if libuuid is installed : [xrootdtest@c340sev xrootd]$ rpm -qa | grep uuid uuid-devel-1.6.2-45.fc31.x86_64 uuid-c++-1.6.2-45.fc31.x86_64 libuuid-2.34-3.fc31.x86_64 uuid-c++-devel-1.6.2-45.fc31.x86_64 uuid-1.6.2-45.fc31.x86_64 in python3 i have this : [xrootdtest@c340sev xrootd]$ python3 Python 3.7.5 (default, Oct 17 2019, 12:16:48) [GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pkgconfig >>> print( pkgconfig.exists( 'uuid-dev' )) False Does anyone have any idea what is going on? Thank you! Adrian

5 7

google cloud print ending
by Neal Becker 26 Nov '19

26 Nov '19

So what to do now? On my android device, I installed a mopria app, and it finds my brother laser printer just fine. But to print from my linux desktop, I've never setup a system printer, just depended on printing to google cloud via chrome. From what info I found via google search, cups should just work with mopria- enabled printers (like mine). According to articles I found cups should just detect it as available network printers. So I tried it. kde printer config and system-config-printers both detect nothing as available network printers. Mopria app on my android detects it just fine. Both connected to same wifi. This is a pretty complete F31 workstation install. Any ideas how to debug this and/or fix it? Thanks, Neal

3 2