Hi all,
After a TW update in the last few weeks, ssh with ssh-agent did
no longer work with my established setup. (I did not verify the
problem with a pristine user account, though).
I have set up my system (a loooong time ago... ;)) so that the
ssh key is stored somehow in gnome-keyring-daemon and gets unlocked
upon login.
The ssh-agent knows the key:
seife@strolchi:~> ssh-add -l
1024 SHA256:96ejSSf7kXLZRWhEE4oJUk20+RukUpSJOu4elrVABCU seife@strolchi (RSA)
...but it did not work:
seife@strolchi:~> ssh server
sign_and_send_pubkey: signing failed: agent refused operation
Password:
If I now refreshed the agent with "ssh-add", and entered my
passphrase, then ssh without password did work.
The journal showed the following:
Apr 08 18:28:41 strolchi gnome-keyring-daemon[1868]: the /usr/bin/ssh-add command failed: Child process exited with code 1
Apr 08 18:28:41 strolchi gnome-keyring-daemon[1868]: ssh_askpass: exec(/usr/lib/gcr-ssh-askpass): No such file or directory
So the solution was to install the gcr-ssh-askpass package (which
provides /usr/lib/gcr-ssh-askpass) and now everything is working
as before.
Hope this helps someone ;-)
--
Stefan Seyfried
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi, everyone!
My laptop is an Acer Aspire E15 with a built-in Bluetooth 4.0 adapter,
namely Qualcomm Atheros Bluetooth 4.0 (ID 04ca:3014).
I had to tweak Leap 42.3 for it work, here is a brief of what I did:
https://forums.opensuse.org/showthread.php/524410-Qualcomm-Atheros-Bluetoot…
Then I was using the kernel-default 4.13.6 and kernel-firmware from
the Kernel:stable OBS repo.
When I upgraded to Leap 15.0 Beta, I switched to the kernel-default
4.12.14 and kernel-firmware from the Leap 15.0 OSS repo.
Now, even though my Bluetooth adapter is working, I am not able to
pair with my headset (Philips SHB3060) using the A2DP profile.
I installed Blueman, which gives some more control and information
than GNOME's System Settings. Using Blueman, when I try to change my
headset to the A2DP profile I get this:
"Failed to change profile to a2dp_sink"
I tested downloading Leap 15.0 GNOME Live, flashing it into an USB
stick and booting from it. Bluetooth was not recognized at first, but
blacklisting the acer_wmi module (see my forum post for details) and
rebooting was enough. Then, Bluetooth worked normally (including
switching to the A2DP profile).
So, I believe it is a problem on my setup, not on Leap 15.0 itself,
i.e. a clean install would be half of the solution, the another half
blacklisting the acer_wmi module and rebooting.
Any ideas on what changed and how I can make the A2DP profile work again?
Thank you!
Antonio
The Linux Kamarada Project
http://kamarada.github.io/
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Unfortunately I can't say when exactly this happened, but while I was
updating a Win7 laptop today I tried to log into it via krdc and that no
longer works. At first I thought it was related to the new firewalld,
but apparently there's some problem with Xcb?
Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50790, resource id: 56623169, major code: 19 (DeleteProperty), minor code: 0
Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50800, resource id: 56623169, major code: 19 (DeleteProperty), minor code: 0
Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50801, resource id: 56623169, major code: 18 (ChangeProperty), minor code: 0
Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50802, resource id: 56623169, major code: 19 (DeleteProperty), minor code: 0
Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50803, resource id: 56623169, major code: 19 (DeleteProperty), minor code: 0
Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50804, resource id: 56623169, major code: 19 (DeleteProperty), minor code: 0
Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50805, resource id: 56623169, major code: 7 (ReparentWindow), minor code: 0
Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50806, resource id: 56623169, major code: 6 (ChangeSaveSet), minor code: 0
Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50807, resource id: 56623169, major code: 2 (ChangeWindowAttributes), minor code: 0
Mar 14 19:48:40 Gertrud kwin_x11[2209]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 50808, resource id: 56623169, major code: 10 (UnmapWindow), minor code: 0
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
DIY Stuff:
http://Synth.Stromeko.net/DIY.html
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hello,
this looks like we have some haskell issue in Tumbleweed:
> Package 'xmonad' is not available in your repositories. Cannot
> reinstall, upgrade, or downgrade.
Is there some more information somewhere?
Thanks
Michal
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hello everyone,
Firstly I am cross posting this across a number of mailinglists because
this post affects several, but I would ask that you keep your replies /
feedback on the openSUSE project list as not to fragment discussion.
It has been raised with the board by several members of the community
that some of our mailinglists have not been working as effectively as we
would like. As such and as raised in our annual discussion with the
community during the conference, the board has decided to take a couple
of steps that we hope will resolve these issues or that will at least be
a starting point in resolving these issues.
Firstly we have created a new opensuse-support(a)o.o mailing list, we as
the board felt that in the transition from factory -> tumbleweed in
particular the change in role for opensuse(a)o.o did not work well and in
many cases there was an attitude that factory/tumbleweed issues should
still be posted on the factory mailing list. As such we have created the
support mailing list to help clarify these changes in policy that we
don't believe worked when we tried to change them last time. In short we
would like you to use opensuse-support(a)o.o whenever you require support
whether it is for Tumbleweed, Leap (regardless of whether you are using
a Leap beta or not) or any other project under the openSUSE umbrella.
This brings us to the next issue, posting bugs / bug reports on mailing
lists rather then bugzilla. This is a practice we would like to see
stopped and we will be gently reminding people if they continue posting
bugs on mailinglists, this especially includes if a package /
application breaks when updating tumbleweed / leap (including beta's).
We would ask that you search for your issue prior to reporting but in
case you accidentally report a duplicate bug its easy for us to mark it
as such, also if you report something that is intentional and not a bug
it doesn't take long to mark it as such, so if in doubt file a bug
rather then posting to a mailing list, there is useful information for
filing bugs at the following links [1][2]. But if you are really stuck
with trying to file your bug the friendly people at opensuse-support(a)o.o
can support you through the process.
The board hopes that with the changes outlined above the contents of the
opensuse-factory(a)o.o will go back to just being general distro
development discussion so if your post to openSUSE factory is something
other then that think twice about where the more appropriate place to
post is. The new tumbleweed snapshots will continue to be posted to
factory but we would ask you do not reply to them in order to report
issues / bugs. If a bug is reported that a package maintainer believes
will cause significant issues for most tumbleweed users ie not being
able to boot / login or severe data loss we still invite the maintainer
to post a warning to opensuse-factory but such issues happen very rarely
and as such we don't expect to see many such posts.
The board has decided that it would like to see how well these changes
work before deciding to add / remove / change openSUSE's mailing lists
further. Although we have discussed several other possibilities that we
could also try in the future.
1. https://en.opensuse.org/openSUSE:Bug_reporting_FAQ
2. https://en.opensuse.org/openSUSE:Submitting_bug_reports
--
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hi All,
In both Leap & Tumbleweed we currently have the following logic for
choosing which tool manages your network after installation
"IF laptop AND NetworkManager is being installed THEN use
NetworkManager, ELSE wicked"
I've noticed an increasing trend that this can lead to confusion.
Many users from other distributions expect NetworkManager on their
desktops regardless of whether they are using a laptop or a desktop.
GNOME expects NetworkManager by default and shows a rather unpleasant
error when loading up the settings screen without it.[1]
There are certainly classes of hardware where NetworkManager might be
wanted that will never match "IF laptop" - eg. my personal Inter
Compute Stick.
And "IF laptop" is dependant on YaST correctly detecting you're using
a laptop, which isn't 100% accurate, so occasionally even laptops
might end up with wicked unexpectedly.
I would like to propose a possible solution.
It looks like we should be able to pin the choice of network tool to
specific system role.
I would like to propose that the installation options KDE and GNOME
therefore always have NetworkManager by default
Server & Transactional will always have wicked by default
Custom will keep the current "autodetect" behaviour, because we cant
be sure that the environment that the user is installing has support
for NetworkManager in this case.
Whatever is setup "by default" during installation will be able to be
changed in YAST after the installation, just like it is today.
What do we all think? If there is strong support for this idea I think
Ludwig is prepared to let me try and slip it in as a late feature for
Leap 15, so please let your opinions be heard loudly and quickly
either way.
Regards,
Richard
[1] http://paste.opensuse.org/33301696
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hello all,
We will have to split a bit the d:l:py due to its monstrous size (2700
packages) where we are unable to verify the stack actually kinda works
before Tumbleweed integration.
We will split it based on common purpose and use d:l:py as base:
devel:languages:python:django
devel:languages:python:azure
devel:languages:python:aws
...
If you happen to have some packages or interest in python modules and
think of some connection between couple of them please drop me an email
for subproject creation and I will happily create it for you and set it
up for TW integration.
As a bit additional tweak I would move all of the non-Tumbleweed
integrated stuff in to different project.
At this moment it is full of various linked packages and things that
were only added to develprj without being submitted to Tumbleweed.
This prompted people to add this project on their released openSUSE
versions (leading to quite interestingly broken systems if they do
zypper dup with vendor change)...
The change will be done by creating special project d:l:py:misc that
would have building enabled but publishing disabled.
This will hopefully motivate people to properly integrate the packages
while not losing all the work that was done on them so far.
Cheers
Tom
[1] https://build.opensuse.org/project/show/devel:languages:python
Hi all,
As many people are aware the sharing of code between Leap and SLE
combined with SUSE's "Factory First" policy has often lead to the need
for openSUSE community members needing to read bugs that have been
marked as private because they were originally created for SLE.
For some time SUSE has been happy for SUSE employee's to review and
disclose the contents of private bugs as long as we don't share any
customer information. We can either do this by making any such
confidential info private in the bug should it exist then making the bug
public or in other cases providing a summary of the bug and discussion,
even if in some cases all we can say is "this is a private customer feature"
In order to make this process slightly easier and more formal during las
weeks board discussion the board decided to the mailing list
opensuse-bugshare(a)opensuse.org where community members can send an email
then a volunteer SUSE employee can read the bug report then either open
it or provide a summary.
Currently this is a short term solution, SUSE Engineering understands
this problem and will be working toward a better solution longer term.
If you are a SUSE employee and you are happy to help with this process
shoot me an email and i'll get you subscribed to the list.
Cheers
--
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hi all,
We have pretty strict requirements how the group tags are shown. [0]
But there are only 2 ways to use it, 1) yast view based on groups 2)
using rpm -q to get information for the individual package.
For all other purposes from zypp/packagekit this stuff is ignored.
In general it does not really make sense to install packages based on
groups. As Fedora already deprecated this tag it would make sense for
us to drop it too [1][2].
Proposed change would be to kill the Yast UI and then have spec-cleaner
to drop the part where needed. It won't break on older releases as it
would simply have Undefined as a group.
Cheers
Tom
[0] https://en.opensuse.org/openSUSE:Package_group_guidelines
[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sectio
ns
[2] https://fedoraproject.org/wiki/RPMGroups
Is anyone else experiencing issues starting up the docker daemon?
sudo systemctl start docker
Job for docker.service failed because a timeout was exceeded.
See "systemctl status docker.service" and "journalctl -xe" for details.
systemctl status docker.service
● docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled;
vendor preset: disabled)
Active: failed (Result: timeout) since Tue 2018-05-29 11:11:06 BST; 9s ago
Docs: http://docs.docker.com
Process: 24544 ExecStart=/usr/bin/dockerd --containerd
/run/containerd/containerd.sock --add-runtime
oci=/usr/sbin/docker-runc $DOCKER_NETW>
Main PID: 24544 (code=killed, signal=KILL)
May 29 11:08:06 linux-9wl3 dockerd[24544]:
time="2018-05-29T11:08:06.532027695+01:00" level=warning msg="Your
kernel does not support cgroup >
May 29 11:08:06 linux-9wl3 dockerd[24544]:
time="2018-05-29T11:08:06.532087206+01:00" level=warning msg="Your
kernel does not support cgroup >
May 29 11:08:06 linux-9wl3 dockerd[24544]:
time="2018-05-29T11:08:06.533562226+01:00" level=info msg="Loading
containers: start."
May 29 11:09:36 linux-9wl3 systemd[1]: docker.service: Start operation
timed out. Terminating.
May 29 11:09:36 linux-9wl3 dockerd[24544]:
time="2018-05-29T11:09:36.418326793+01:00" level=info msg="Processing
signal 'terminated'"
May 29 11:11:06 linux-9wl3 systemd[1]: docker.service: State
'stop-sigterm' timed out. Killing.
May 29 11:11:06 linux-9wl3 systemd[1]: docker.service: Killing process
24544 (dockerd) with signal SIGKILL.
May 29 11:11:06 linux-9wl3 systemd[1]: docker.service: Main process
exited, code=killed, status=9/KILL
May 29 11:11:06 linux-9wl3 systemd[1]: docker.service: Failed with
result 'timeout'.
May 29 11:11:06 linux-9wl3 systemd[1]: Failed to start Docker
Application Container Engine.
This was working the last time I tried, so I'm not entirely sure
what's going on.
I even tried re-installing docker itself as well as deleting all of
/var/lib/docker - but I still get the same issue.
Mike
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org