Re: Gnome Screenshot not saving to clipboard
No, I do have Wayland installed but I'm running Xorg: $ ps ax | grep xorg > 39677 tty7 Sl+3:13 /usr/lib/xorg/Xorg vt7 -displayfd 3 -auth > /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 > No Wayland running: $ ps ax | grep -i wayland > 48911 pts/0S+ 0:00 grep -i wayland > But when I try to remove the xwayland package: # apt purge xwayland > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages were automatically installed and are no longer > required: > alacarte gir1.2-gmenu-3.0 gnome-applets gnome-applets-data gnome-panel > gnome-panel-data gnome-session-common libcpupower2 > Use 'apt autoremove' to remove them. > The following packages will be REMOVED: > gdm3* gnome-session* gnome-session-bin* gnome-session-flashback* > gnome-shell-extensions* xwayland* > 0 upgraded, 0 newly installed, 6 to remove and 1 not upgraded. > After this operation, 11.4 MB disk space will be freed. > Do you want to continue? [Y/n] > Regards On Tue, Apr 14, 2020 at 5:31 PM Liam O'Toole wrote: > On Tue, 14 Apr, 2020 at 16:02:07 +, Paulo Roberto wrote: > >Hello. > >The gnome-screenshot a few updates ago stopped working properly. > >It's not saving to the clipboard anymore. > >When I run: > > > >$ gnome-screenshot -a -c > > > >It activates the selection cursor, after selection it plays the sound. > >But nothing is saved to the clipboard. > > [...] > > Are you running GNOME on Wayland, by any chance? If so, try on Xorg > instead. > >
Gnome Screenshot not saving to clipboard
Hello. The gnome-screenshot a few updates ago stopped working properly. It's not saving to the clipboard anymore. When I run: $ gnome-screenshot -a -c > It activates the selection cursor, after selection it plays the sound. But nothing is saved to the clipboard. If I try to save it to a file, it works perfectly: $ gnome-screenshot -a -f /tmp/screenshot.png > The gnome shortcut works, that is, it calls the gnome-screenshot, but the problem is the same, it does not save to the clipboard. The problem is the same even if I do not use the area selection feature: $ gnome-screenshot -c > I'm running Debian Testing and the gnome-session and gnome-screenshot versions are: > > gnome-session 3.36.0-2 >all GNOME Session Manager - GNOME 3 session > gnome-screenshot3.36.0-2 > amd64screenshot application for GNOME > I did an experiment downgrading the version of gnome screenshot to the version 3.30.0-2 but the problem persisted: > gnome-screenshot 3.30.0-2 >amd64screenshot application for GNOME > I'd like some help on how to debug this problem and fix it. Thanks in advance. Kind regards. Paulo
Re: buster netinst timezone
On Wed, 28 Aug 2019 at 19:25 David Wright wrote: > On Mon 12 Aug 2019 at 08:38:47 (-0400), Greg Wooledge wrote: > > On Sat, Aug 10, 2019 at 12:16:04PM -0500, David Wright wrote: > > > If you're desparate to get the timezone altered earlier in your > > > installation process, you could always do it manually: try switching > > > to VC2 and editing the file /target/etc/timezone to the string UTC > > > (the alternatives are simply the names of the files in > > > /usr/share/zoneinfo, including subdirectories). Obviously wait until > > > the file exists. (I've not tried this so I don't know when that is.) > > > > I'm skeptical that this would be sufficient. Debian actually stores the > > system's default timezone in *two* different places, using two completely > > different mechanisms. I have been led to believe that one of these is > > "standard" for GNU/Linux-based systems, and the other is for backward > > compatibility. > > Yes, you're right. > > > wooledg:~$ ls -ld /etc/*time* > > -rw-r--r-- 1 root root 46 Apr 10 2017 /etc/adjtime > > lrwxrwxrwx 1 root root 36 Apr 1 08:58 /etc/localtime -> > /usr/share/zoneinfo/America/New_York > > -rw-r--r-- 1 root root 17 Apr 1 08:58 /etc/timezone > > > > The first one is the /etc/timezone file, which as you say, is a > > simple text file that a (root) user can edit. I believe this is the > > backward-compatibility one. > > And that's the one I find useful, in that a lot of applications honour > a value for TZ, which needs to be the text version. I always have a > link to /etc/timezone as ~/.timezone, and TZ is set to its value in > my startup files, which makes it easy to run a session in a > contradictory timezone if I wish. > > > The second one is the /etc/localtime symbolic link, which needs to point > > to an existing binary time zone data file in /usr/share/zoneinfo. The > > symbolic link can be re-pointed by hand; the binary data file should not > > be edited by hand. > > I assume the system is interested in this one because it needs the > actual rules and not just the name of the timezone. Otherwise the > system wouldn't be able to junp the clocks at the appropriate times. > > > Running dpkg-reconfigure tzdata changes both of these, so that all the > > programs work, regardless of which one they choose to honor. Manually > > changing just *one* of them would probably leave the system in an > > inconsistent state, where some programs display the correct time zone, > > and others do not. > > Well, a system running on a UTC hardware clock might have different > applications displaying different times, and writing their logs > accordingly, but the effects shouldn't be damaging. In fact, that > is exactly what is happening during the installation itself: the > major part of the log is in UTC, interspersed with segments in > local time from the likes of useradd and groupadd. > > I couldn't speak for users who have a non-UTC clock. > > I would expect anyone using my desparate [sic] tip would confirm > their timezone in the Debian™ manner as soon as practicable. > I just checked the link/file on a recently-installed buster, and the > timestamps indicate that they're created at the start of the main > tranche of package installation, when /var/log/syslog shows¹ > > Aug 22 01:19:31 in-target: Setting up tzdata (2019b-0+deb10u1) ... > Aug 22 01:19:31 in-target: > Aug 22 01:19:33 in-target: > Aug 22 01:19:33 in-target: Current default time zone: 'America/Chicago' > Aug 22 01:19:33 in-target: Local time is now: Wed Aug 21 20:19:33 CDT > 2019. > Aug 22 01:19:33 in-target: Universal Time is now: Thu Aug 22 01:19:33 UTC > 2019. > Aug 22 01:19:33 in-target: Run 'dpkg-reconfigure tzdata' if you wish to > change it. > Aug 22 01:19:33 in-target: > Aug 22 01:19:33 in-target: Setting up linux-image-4.19.0-5-686-pae > (4.19.37-5+deb10u2) ... > > As dpkg gets set up around the same point, I suppose one could try running > # /target/usr/sbin/dpkg-reconfigure tzdata > in a VC at any time after this, though one might need to wait for a > pause in proceedings (like the popcon question) to avoid any file locking. > > AFAICT the clock question at the end (UTC yes/no) only involves adjtime. > > > I don't have any kind of statistics for how many programs use one vs. > > the other. It's not trivial to find out. > > I guess it ought to depend on whether the program is concerned only > with the here and now (use timezone), or whether it takes into account > past history. Precisely 24 weeks ago, the wall time was the same in > the afternoon as now (though someone in the UK would disagree). > 25 weeks ago, it was still morning, an hour earlier. For that > determination, you want the file pointed to by localtime. > > ¹ Note that tzdata gets installed and set up twice, the first time > being the .deb from the iso, the second from the mirror. The log from > the first time looks like > > Aug 22 00:56:21 debootstrap: Setting up tzdata (2019a-1) ... > Aug 22 00:56:23 debootstrap: > Aug 2
Re: Gnome strange behavior while typing in some windows
Mark, I searched for "input method" but I couldn't find anything relevant (at least not for me). In Gnome Control Center -> Region & Language I have two Input Sources: Portuguese (Brazil) and English (US) In Input Source Options I have "Use the same source for all windows" checked. In Gnome Control Center -> Devices - > Keyboard -> Keyboard Shortcuts -> Typing Switch to next input source = Super + Space Switch to previous input source = Shift + Super + Space Patrick also suggested the problem was with the input method and mentioned the same issue with Japanese and that it could be the IM editor activated. I found 2 INPUT METHOD tools in the menu: Applications -> System Tools -> The first one (blue icon) opens the uim-pref-gtk. In the Global Settings there was a check box "Input method toggle" checked with Input method toggle key set to: "space" I disabled it, but the behavior persisted. The second tool is the Input Method Configuration (im-config) It starts with the following text: "Current configuration for the input method: * Active configuration: missing (normally missing) * Normal automatic choice: none (normally ibus or fcitx or uim) * Override rule: zh_CN,fcitx:zh_TW,fcitx:zh_HK,fcitx:zh_SG,fcitx * Current override choice: (en_US) * Current automatic choice: none * Number of valid choices: 1 (normally 1) The override rule is defined in /etc/default/im-config. The configuration set by im-config is activated by re-starting X. Explicit selection is not required to enable the automatic configuration if the active one is default/auto/cjkv/missing." And after I went to the steps of configuration selecting the recommendations, it outputs: "Keeping the user configuration /home/myuser/.xinputrc as missing. Automatic configuration selects: none This does not set any IM from im-config. This is the automatic configuration choice if no required IM packages are installed. If a daemon program for the previous configuration is re-started by the X session manager, you may need to kill it manually with kill(1). See im-config(8) and /usr/share/doc/im-config/README.Debian.gz for more. Everything was working fine 1 week ago. I could type SHIFT + SPACE and a space character would appear. I just updated the system. Any more ideas? Thanks in advance. Regards. On Sun, Dec 10, 2017 at 2:22 PM, Mark Fletcher wrote: > On Thu, Dec 07, 2017 at 11:03:04PM +, Paulo Roberto wrote: > > Roberto, I figure out how to trigger and disable the problem and I think > > it's a BUG. > > > > The problem occurs when I press SHIFT + SPACE (together). > > > > I went though the list of shortcuts in the Gnome Control Center under > > Devices ->Keyboard. No shortcut is set for SHIFT + SPACE > > > > As I told you before, Input Source Options is set to: "Use the same > source > > for all windows" > > But the shortcuts to change input, in case it was set otherwise are: > SUPER > > + SPACE and SHIFT + SUPER + SPACE. > > > > Before yesterday when I typed SHIFT + SPACE I'd got a space character, > now > > I have this weird behavior that I don't even know what it means. > > > > The more you describe this issue, the more it sounds like an input > system for some other language. What you are describing is EXACTLY the > behaviour I get (and want) when typing in Japanese. To know what kanji > character to use for what I am typing, the input system has to see > several keypresses' worth of input. It lets me type that input, > underlining the part that it is watching, waiting until I have typed > enough for it to figure out what I mean, or until I press the space bar > to say "that is all you are getting, go figure it out" or Enter which > means "I want you to keep this text exactly as I typed it, don't try to > interpret". I use the input system Anthy which I believe works with > multiple languages. There are others though. > > And SHIFT + SPACE is the default method for switching between English > and Japanese input on such systems. > > It doesn't have to be something obvious like Japanese -- you'd know > immediately if it were because it would replace the regular alphabet > characters with Japanese hiragana characters as you type -- but maybe > some language with lots of accents etc that needs to see more than one > letter you are typing before knowing what character to use for what you > are typing? Or an input method that chooses to work that way even if > that isn't the only way that could work for that language? > > What languages do you have installed? And what do you find if you search > your system for "input method"? > > Mark > >
Re: Gnome strange behavior while typing in some windows
Roberto, I figure out how to trigger and disable the problem and I think it's a BUG. The problem occurs when I press SHIFT + SPACE (together). I went though the list of shortcuts in the Gnome Control Center under Devices ->Keyboard. No shortcut is set for SHIFT + SPACE As I told you before, Input Source Options is set to: "Use the same source for all windows" But the shortcuts to change input, in case it was set otherwise are: SUPER + SPACE and SHIFT + SUPER + SPACE. Before yesterday when I typed SHIFT + SPACE I'd got a space character, now I have this weird behavior that I don't even know what it means. Thank you again for your help. Regards. On Thu, Dec 7, 2017 at 8:51 PM, Paulo Roberto wrote: > I had already checked it as well. > Use the same source for all Windows is checked. > > In the same window or tab it changes the behavior during user (typing). > > Do you know any log that could help? > > > On Thu, Dec 7, 2017 at 6:41 PM, Roberto C. Sánchez > wrote: > >> On Thu, Dec 07, 2017 at 05:51:01PM +, Paulo Roberto wrote: >> >Roberto, >> > >> >The first thing I checked was the layout. >> >Nothing changed. >> >And I don't think is related to shortcut keys, because clicking in a >> >different tab, and the problem >> >goes away for that tab. >> >> Paulo, >> >> In "Region and Language", under "Input Source Options" do you have "Use >> the same source for all windows" or "Allow different sources for each >> window"? >> >> Regards, >> >> -Roberto >> >> -- >> Roberto C. Sánchez >> >> >
Re: Gnome strange behavior while typing in some windows
I had already checked it as well. Use the same source for all Windows is checked. In the same window or tab it changes the behavior during user (typing). Do you know any log that could help? On Thu, Dec 7, 2017 at 6:41 PM, Roberto C. Sánchez wrote: > On Thu, Dec 07, 2017 at 05:51:01PM +0000, Paulo Roberto wrote: > >Roberto, > > > >The first thing I checked was the layout. > >Nothing changed. > >And I don't think is related to shortcut keys, because clicking in a > >different tab, and the problem > >goes away for that tab. > > Paulo, > > In "Region and Language", under "Input Source Options" do you have "Use > the same source for all windows" or "Allow different sources for each > window"? > > Regards, > > -Roberto > > -- > Roberto C. Sánchez > >
Re: Gnome strange behavior while typing in some windows
Roberto, The first thing I checked was the layout. Nothing changed. And I don't think is related to shortcut keys, because clicking in a different tab, and the problem goes away for that tab. It's a very weird scenario. I started writing this e-mail with the problem in the current window and when I got in the third line it went back to normal, and now it just happened again. Another point is that I can type a word with 100 characters, if I type a space or a comma for example, the word persists. If I press a control key (like ESC, or PrintScreen) or click out of the text field the word disappear if I never had written it. I can switch my layout between Portuguese (Brazil) and English (US) but the problem persist independently. Anyway I don't have any shortcut key configuration for changing layout. Thanks for the help. I look forward to hear from you. Regards. Paulo On Thu, Dec 7, 2017 at 5:12 PM, Roberto C. Sánchez wrote: > On Thu, Dec 07, 2017 at 04:07:24PM +0000, Paulo Roberto wrote: > >If I change window or even tabs, the typing works perfectly in the > new tab > >or window but persists in the previous one when I come back to it. > >The problem comes and goes and I don't know the exact way to > replicate it. > >I start using a tab or window for a while and it happens. > > Paulo, > > It sounds like you might have something going on with your keyboard > layouts and the shortcut key combination that changes the layout. In my > case, I tend to use L_SHIFT+CAPS_LOCK to change from a dead keys layout > to a non-dead keys layout. However, I recently installed Debian on a > new machine and found that the default had changed because the key > combination on the newly installed machine was SUPER+SPACE. > > You may want to check your "Region and Language" settings in GNOME to > see what layouts have key combinations associated with them. That may > tell you why your layout changes when you don't expect it. > > Regards, > > -Roberto > > -- > Roberto C. Sánchez > >
Gnome strange behavior while typing in some windows
Since yesterday my Gnome started to present some weird behavior in random Windows. While I'm typing in Terminator or Firefox, for example, everything I type get underlined until I press some key that represents a blank character (enter, space, etc or parentheses, comma, or other non letter number chars). When the window has this issue I can't type words with accent, the accent always appears after the word. While in fields with auto complete (example Firefox text fields), the auto complete doesn't work, If I insert the blank character it works. In Terminator, when I press CTRL +SHIFT +X the problem is solved and the typing comes back to normal in the specified Windows or tab. In Firefox I don't know how to solve it. If I change window or even tabs, the typing works perfectly in the new tab or window but persists in the previous one when I come back to it. The problem comes and goes and I don't know the exact way to replicate it. I start using a tab or window for a while and it happens. Version of my Gnome Shell gnome-shell 3.26.2-1 I can't even take a snapshot of the problem, because when I press the Print Screen key, the word I was typing disappear and then the screenshot happens. If I click outside the place of the current keyboard focus in the middle of a word (without inserting the blank character) the current word also disappear. Thanks in advance. I look forward to hear from you guys. Paulo Roberto.
ICEDOVE - Always asking for login keyring password
Hi, folks, I'm using Icedove with OpenPGP enabled by Enigmail. Every time I open the application and send my first e-mail, it prompts me for my PGP key. After inserting it and mark to remember, it asks for my Gnome Keyring password. After that, everything works fine and I can send e-mails without been asked for any password any more. The screen that prompts for my login password have the following message: "Enter password to unlock your Keyring The login keyring did not get unlocked when you logged into your computer" I already changed my password though the gnome-control-center but it did not solve the problem. Anyone have any idea how to unlock the "login keyring" when I log in ? Thanks in advance. Regards. Paulo Roberto Brandão
Re: SSHD AllowUsers not limiting users anymore
Hi Chris, I'm not aware of anything special in my PAM configuration, I think It is still using the default configs. user1 is a complete different user than any other, It has its unique user id. If a create a brand new user, the same problem happens. I could say I'm using the correct /etc/ssh/sshd_config because other changes to the file are read. To be sure, as you can see at my last e-mail, I passed the -f command line option to run sshd. The DenyUsers option is not working as well. I tried it with user1 and it does not block the user. Below follow my /etc/pam.d/sshd, if you need any other file, please, let me know. Thanks again for your help. # PAM configuration for the Secure Shell service # Standard Un*x authentication. @include common-auth # Disallow non-root logins when /etc/nologin exists. accountrequired pam_nologin.so # Uncomment and edit /etc/security/access.conf if you need to set complex # access limits that are hard to express in sshd_config. # account required pam_access.so # Standard Un*x authorization. @include common-account # SELinux needs to be the first session rule. This ensures that any # lingering context has been cleared. Without this it is possible that a # module could execute code in the wrong domain. session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close # Set the loginuid process attribute. sessionrequired pam_loginuid.so # Create a new session keyring. sessionoptional pam_keyinit.so force revoke # Standard Un*x session setup and teardown. @include common-session # Print the message of the day upon successful login. # This includes a dynamically generated part from /run/motd.dynamic # and a static (admin-editable) part from /etc/motd. sessionoptional pam_motd.so motd=/run/motd.dynamic sessionoptional pam_motd.so noupdate # Print the status of the user's mailbox upon successful login. sessionoptional pam_mail.so standard noenv # [1] # Set up user limits from /etc/security/limits.conf. sessionrequired pam_limits.so # Read environment variables from /etc/environment and # /etc/security/pam_env.conf. sessionrequired pam_env.so # [1] # In Debian 4.0 (etch), locale-related environment variables were moved to # /etc/default/locale, so read that as well. sessionrequired pam_env.so user_readenv=1 envfile=/etc/default/locale # SELinux needs to intervene at login time to ensure that the process starts # in the proper default security context. Only sessions which are intended # to run in the user's context should be run after this. session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open # Standard Un*x password updating. @include common-password On Thu, Nov 12, 2015 at 12:34 PM, Christoph Anton Mitterer < cales...@scientia.net> wrote: > On Wed, 2015-11-11 at 20:20 -0200, Paulo Roberto wrote: > > The option AllowUsers of /etc/ssh/sshd_config stopped working. > I did a small check, and it still works here, as expected... anything > special with your PAM? Are you sure that you checked on the right hosts > with the right sshd_config in place? Or could user1 be a synonym to the > allowed one (i.e. same UID)?) > > Cheers, > Chris.
SSHD AllowUsers not limiting users anymore
Dear list, I need some help. After upgrading the openssh-server package to the version: ii openssh-server1:6.9p1-2+b1 amd64 secure shell (SSH) server, for secure access from remote machines The option AllowUsers of /etc/ssh/sshd_config stopped working. Any user can log through ssh even not present in this option. Before the upgrade everything worked fine. I tested the same sshd_config file in my OpenBSD box and there everything worked as expected. OpenSSH_6.7, LibreSSL 2.0 Could it be a BUG? Below follow the sshd debug and my /etc/ssh/sshd_config Thanks in advance for your time and help. # /usr/sbin/sshd -D -f /etc/ssh/sshd_config -d debug1: sshd version OpenSSH_6.9, OpenSSL 1.0.2d 9 Jul 2015 debug1: private host key #0: ssh-rsa SHA256:Qt/Tvla7baMNHE6zEeKElm9sNWGlRYUjuIDT/tq7D/c debug1: private host key #1: ssh-dss SHA256:jZ4QK8dI46HvGFEMgPnN1C9jcVDYIRSk0UKZhT7fjzM debug1: private host key #2: ecdsa-sha2-nistp521 SHA256:tpsp3EYEixbFgA4TVXiZxxu2ZGDwl4GTGYcBlnk+XiY debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-f' debug1: rexec_argv[3]='/etc/ssh/sshd_config' debug1: rexec_argv[4]='-d' Set /proc/self/oom_score_adj from 0 to -1000 debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: Bind to port 22 on ::. Server listening on :: port 22. debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 200.137.21.34 port 53540 on 192.168.1.3 port 22 debug1: Client protocol version 2.0; client software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x0400 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Debian-2+b1 debug1: permanently_set_uid: 112/65534 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp521 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: client->server aes256-...@openssh.com none [preauth] debug1: kex: server->client aes256-...@openssh.com none [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] debug1: SSH2_MSG_NEWKEYS received [preauth] debug1: KEX done [preauth] debug1: userauth-request for user user1 service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug1: user user1 does not match group list hg-users at line 93 debug1: PAM: initializing for "user1" debug1: PAM: setting PAM_RHOST to "200.137.21.34" debug1: PAM: setting PAM_TTY to "ssh" debug1: userauth-request for user user1 service ssh-connection method publickey [preauth] debug1: attempt 1 failures 0 [preauth] debug1: test whether pkalg/pkblob are acceptable [preauth] debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/user1/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/user1/.ssh/authorized_keys2 debug1: Could not open authorized keys '/home/user1/.ssh/authorized_keys2': No such file or directory debug1: restore_uid: 0/0 Failed publickey for user1 from 200.137.21.34 port 53540 ssh2: RSA SHA256:Rf4KIuZGFt5aUAnoA890Why0iSbfItRf/shVfCEEmuw debug1: userauth-request for user user1 service ssh-connection method password [preauth] debug1: attempt 2 failures 1 [preauth] debug1: PAM: password authentication accepted for user1 debug1: do_pam_account: called Accepted password for user1 from 200.137.21.34 port 53540 ssh2 debug1: monitor_child_preauth: user1 has been authenticated by privileged process debug1: monitor_read_log: child log fd closed debug1: PAM: establishing credentials User child is on pid 13122 debug1: SELinux support disabled debug1: PAM: establishing credentials debug1: permanently_set_uid: 1000/1000 debug1: ssh_packet_set_postauth: called debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_global_request: rtype no-more-sessi...@openssh.com want_reply 0 debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_new: session 0 debug1: SELinux support disabled debug1: session_pty_req: session 0 alloc /dev/pts/4 debug1: server_input_channel_req: channel 0 request env reply 0 debug1: session_by_channel: session 0 channel 0 debug
Re: skype pauses vlc
Hi Paul and Raph, In my case there is a behavior not so stable. Some times the Skype pause the audio in VLC and it does not resume and some times it resumes. I'm using the new testing. On Thu, May 14, 2015 at 1:32 PM, Ralph Katz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 05/14/2015 08:50 AM, Paul Seyfert wrote [snipped]: > > > Hi, > > > since i upgraded from wheezie to jessie I observe that skype is able to > > pause vlc as follows: > > > > vlc plays music > > skype is online > > someone writes me a message > > vlc pauses and skype makes its "blub"-sound to notify me about the > message > > vlc stays paused > > > vlc also gets paused when hitting the "play test sound" button in the > > skype configuration. > > > > Any hints how to prevent skype from sending pause signals? > > Hi Paul -- For me, vlc resumes after skype. Perhaps tinkering with > pulseaudio can help? I have not touched any settings. aplay file.wav > does not get paused. Hope this helps. > > Regards, > Ralph > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJVVM3MAAoJECe2FpioHXO6T1cH/0ysuEm+G9DxQakEjVBq2D4o > tpGBlvb3IFJ+8ng+90g3BQE8Cd2Hf2uwz+XT8lHDkX4JQyykO1XPif1mYlpnxxed > 0gd2ZhY7Ca4hB1N7bwtdKC+r8dK8wghyPkEaAT69Nz5w/Pc11e2c8gaD5uJ/qsjn > IPXxMYaUkv0Wtr5ER2R9WO11FVvPeOTVmqWSLQTHVF0I60Th4YI0bAw87b5Mr7c4 > tuKnlDEqH2lccOyaSPcENMCDi9qYkJlaKiwvUc3ZRCIOAicCC6fz69UFeHdh0b1J > FtkjInGAufVUYpyvGI53yDVpFv+ipJ6QA8YZG1vvQ4cCxa+E1m3XG3Q5nZEAHms= > =IZpP > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/5554ce0e.4050...@rcn.com > >
Re: LSB Raise network interface taking too long
Michael, Yes, I mean Jessie. Sorry. And you were right, removing the /etc/network/if-up.d/openntpd the problem was gone. I assume that this file that comes in the openntpd package should not exist. Am I correct? Thanks a lot for your help. Kind Regards. On Fri, Mar 27, 2015 at 2:14 PM, Michael Biebl wrote: > Am 27.03.2015 um 17:07 schrieb Paulo Roberto: > > Hello, > > > > During the boot, when it's time to bring the interfaces up, this process > > takes more than 5 minutes. > > The below message is displayed on the screen: > > > > A start job is running for LSB: Raise network interface [5:16] > > > > After the timeout the systems works normally. > > > > I'm using Lenny on a 64bit machine and the systemd init system. > > I assume you mean Jessie here. > > > It seams the problem is some race condition that results in a deadlock. > > The systemd is waiting for a condition that never is satisfied. > > .. > > > Mar 27 09:50:36 vali networking[745]: run-parts: executing > > /etc/network/if-up.d/openntpd > > I think the problem is the openntpd hook, which calls > invoke-rc.d openntpd force-reload. > > /etc/init.d/openntpd itself requires $network though. > So this might be the dead lock. > > If you purge openntpd, or remove /etc/network/if-up.d/openntpd, is the > problem gone? > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
LSB Raise network interface taking too long
ntnfs Mar 27 09:50:32 vali networking[745]: run-parts: executing /etc/network/if-up.d/ntpdate Mar 27 09:50:35 vali kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Mar 27 09:50:36 vali networking[745]: run-parts: executing /etc/network/if-up.d/avahi-autoipd Mar 27 09:50:36 vali networking[745]: run-parts: executing /etc/network/if-up.d/avahi-daemon Mar 27 09:50:36 vali networking[745]: run-parts: executing /etc/network/if-up.d/ethtool Mar 27 09:50:36 vali networking[745]: run-parts: executing /etc/network/if-up.d/mountnfs Mar 27 09:50:36 vali networking[745]: run-parts: executing /etc/network/if-up.d/ntpdate Mar 27 09:50:36 vali networking[745]: run-parts: executing /etc/network/if-up.d/openntpd Mar 27 09:55:28 vali systemd[1]: networking.service start operation timed out. Terminating. Mar 27 09:55:28 vali systemd[1]: Failed to start LSB: Raise network interfaces.. Mar 27 09:55:28 vali systemd[1]: Unit networking.service entered failed state. Booting after a #systemctl enable debug-shell.service I could switch to tty9 and when the boot stoped on bringing the interface up I run: # /etc/init.d/networking restart The booting process continued from where it stopped, I didn't need to wait anything and the interfaces were configured successfully. Any idea how to solve that? Tell me if you need anymore details on my configuration. Below are some links I looked at before post here. Thanks in advance. Best Regards. Paulo Roberto PS: [0] - http://forums.debian.net/viewtopic.php?f=5&t=119326 [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771943 [2] -
Problems connecting to Ingenico POS devices with Debian Jessie
Good afternoon,
I'm sending this message here, because the problem is happening only on my
Debian machine.
I'm developing applications for Ingenico POS devices EFT 930S and ICT 220.
They run Telium platform and I use an Windows application to load the files
into the devices.
The vendor provide a Windows Local Loading Tool (LLT) that connects
through their "serial" interface. Actually, it is a USB interface that
works as a serial port.
The tool establishes a PPP link and after that there is a FTP connection.
My environment is a Debian Jessie running *Kernel 3.16.0-4-amd64 #1 SMP
Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux.*
This Debian is a VirtualBox host for a Windows XP SP3 (32 bits) guest
machine that runs the LLT to connect to the terminals.
The version of the VirtualBox is:
*virtualbox-4.34.3.20-96996~Debian~w
amd64 Oracle VM VirtualBox*
It was downloaded from the Oracle Repository.
Some time ago, when I was using a different version of the kernel (I'm not
sure which one right now) everything was working fine. After the update the
things got messy.
I have 2 problems. If the ModemManager daemon is running, it restarts the
device few seconds after it's connected to the machine's USB port. So I
stopped the ModemManager. (problem solved)
The second problem is that the PPP connection is never established.
I activate the USB device on the VirtualBox, the Windows XP detects it, the
LLT recognize that there is a COM port active, but the PPP link is not
established. There is this error RAS 777 that the documentation explain as:
*Terminal is not responding. Check connection (check the serial cable or
USB cable is correctly plugged) and check that terminal is waiting for a
connection. If not check Selecting communication port or Installing the
null modem driver.*
I made all the checks and everything is ok but it keeps returning this
error.
It's valid to point that I use the same VM (in this Debian host) to
connect to other vendors' POS using their own software and my Debian
connects via Minicom to then to get serial output.
Then I exported my VM and used it on a Ubuntu machine, disabled the
ModemManager and everything worked pretty well. (cables and POS devices are
the same)
*The Ubuntu distro is 14.04 and the Kernel 3.13.0-43-generic #72-Ubuntu
SMP.*
I did some tests in the Debian machine with the udev and the Linux is
recognizing the USB device.
I got this in the /var/log/messages when I plugged the device.
*Jan 28 15:53:07 vali kernel: [19860.666924] usb 4-1.4.3.1: new full-speed
USB device number 10 using ehci-pciJan 28 15:53:07 vali kernel:
[19860.776725] usb 4-1.4.3.1: New USB device found, idVendor=079b,
idProduct=0028Jan 28 15:53:07 vali kernel: [19860.776732] usb 4-1.4.3.1:
New USB device strings: Mfr=0, Product=0, SerialNumber=0Jan 28 15:53:07
vali kernel: [19860.777217] cdc_acm 4-1.4.3.1:1.0: ttyACM0: USB ACM
deviceJan 28 15:53:07 vali mtp-probe: checking bus 4, device 10:
"/sys/devices/pci:00/:00:1d.0/usb4/4-1/4-1.4/4-1.4.3/4-1.4.3.1"Jan
28 15:53:07 vali mtp-probe: bus: 4, device: 10 was not an MTP device*
This in the /var/log/kern.log
*Jan 28 15:53:07 vali kernel: [19860.666924] usb 4-1.4.3.1: new full-speed
USB device number 10 using ehci-pciJan 28 15:53:07 vali kernel:
[19860.776725] usb 4-1.4.3.1: New USB device found, idVendor=079b,
idProduct=0028Jan 28 15:53:07 vali kernel: [19860.776732] usb 4-1.4.3.1:
New USB device strings: Mfr=0, Product=0, SerialNumber=0Jan 28 15:53:07
vali kernel: [19860.777179] cdc_acm 4-1.4.3.1:1.0: This device cannot do
calls on its own. It is not a modem.Jan 28 15:53:07 vali kernel:
[19860.777217] cdc_acm 4-1.4.3.1:1.0: ttyACM0: USB ACM device*
And with this udev rule:
*KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="079b",
ATTRS{idProduct}=="0028", MODE="0666", SYMLINK+="telium%n"*
I got the link telium0 in the /dev folder.
But when I activate the device in the VirtualBox, so my VM could see it,
the link disappears but the VM detects the device.
What else could I send to you, so you could help me to solve this problem?
Thanks in advance.
Kind Regards
Paulo Roberto
dhclient release and renew.
Hi all, I would like know if there is a way to have dhclient release and renew for ADSL line. I'm using a machine with dual boot and dhclient is not working for me as it used to. Thanks, Paulo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
