Some months ago it was possible to receive files via bluetooth with TW.
But since some weeks that fails for me. I waited for GNOME 3.20 and the
new bluez in the hope it will fix itself, but the failure remains:
Apr 05 18:01:28 probook obexd[3042]: CONNECT(0x0), (null)(0xffffffff)
Apr 05 18:01:28 probook obexd[3042]: CONNECT(0x0), (null)(0x0)
Apr 05 18:01:32 probook obexd[3042]: PUT(0x2), (null)(0xffffffff)
Apr 05 18:01:32 probook obexd[3042]: open(/home/olaf/.cache/obexd/GSIBFY): No such file or directory (2)
Apr 05 18:01:32 probook obexd[3042]: PUT(0x2), NOT_FOUND(0x44)
Apr 05 18:01:32 probook obexd[3042]: DISCONNECT(0x1), (null)(0xffffffff)
Apr 05 18:01:32 probook obexd[3042]: DISCONNECT(0x1), SUCCESS(0x20)
Apr 05 18:01:32 probook bluetoothd[1520]: Unable to get io data for Object Push: getpeername: Transport endpoint is not connected (107)
Apr 05 18:01:32 probook obexd[3042]: disconnected: Transport got disconnected
Apr 05 18:02:42 probook obexd[3042]: CONNECT(0x0), (null)(0xffffffff)
Apr 05 18:02:42 probook obexd[3042]: CONNECT(0x0), (null)(0x0)
Apr 05 18:02:42 probook obexd[3042]: PUT(0x2), (null)(0xffffffff)
Apr 05 18:02:42 probook obexd[3042]: open(/home/olaf/.cache/obexd/1OLQFY): Operation not permitted (1)
Apr 05 18:02:42 probook obexd[3042]: PUT(0x2), FORBIDDEN(0x43)
Apr 05 18:02:42 probook obexd[3042]: DISCONNECT(0x1), (null)(0xffffffff)
Apr 05 18:02:42 probook obexd[3042]: DISCONNECT(0x1), SUCCESS(0x20)
Apr 05 18:02:42 probook bluetoothd[1520]: Unable to get io data for Object Push: getpeername: Transport endpoint is not connected (107)
Apr 05 18:02:42 probook obexd[3042]: disconnected: Transport got disconnected
First I tried to remove /home/olaf/.cache/obexd, but nothing seems to
feel responsible to create this dir as seen with the first error. Then I
created it with mkdir -m07777, and that just gives the EPERM error as
before. strace shows that it gets some "forbidden" from dbus.
Is receiving files working for anyone else?
Also the rfkill thing does not work reliable. NetworkManager finds the
device according to syslog, but the GNOME bluetooth thing finds nothing.
Something softblocks it:
root@probook:~ # hciconfig -a hci0 reset
Can't init device hci0: Operation not possible due to RF-kill (132)
root@probook:~ # rfkill list all
0: hp-wifi: Wireless LAN
Soft blocked: no
Hard blocked: yes
1: hp-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
4: hci0: Bluetooth
Soft blocked: yes
Hard blocked: no
Need to run 'rfkill unblock 4' manually to get it going. Once that it
done its appearently possible to use the UMTS, and sending a file works
as well.
Olaf
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi,
I've built new package for openSUSE Tumbleweed. Akonadi resource agent for Microsoft Exchange using Exchange Web Services (EWS) protocol.
It's my first package so any test or help is appreciated.
https://build.opensuse.org/package/show/home:hlavki/akonadi-ews
thanks, m.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi,
on OBS a lot of projects are building for Leap 42.2 in both i586 and
X86_64, does this mean Leap 42.2 will be available in 32bit?
Cheers
MH
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
I'd consider adding it as an update, too, to 42.1 and SP1, at least in
aux repositories - preferably to updates :-).
I've spoken with the author of pam_faillock and I believe it to be
superior to pam_tally2, particularly concerning handling of
screensaver handling.
pam_faillock is part of the recommended RHEL configuration for secured
computers and holding out for pam_tally2 also presents a nasty
non-uniformity for nearly the same functionality (although, weaker).
I've asked the author, Tomas Mraz, to make the patch available
standalone - which he has provided here:
http://people.redhat.com/tmraz/pam_faillock/
I would've have submitted my branch against factory pam incorporating
the patch - but unfortunately I seem to be having some
automake/libtool issues in the build that I cannot figure out - so I'm
going to have to leave that effort to someone who knows those build
tools better than I.
I also intend to poke upstream to ask them to reconsider adding that
patch into master.
-Jason
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi *,
I'm still trying to switch somehow automatically between the nvidia and
the nouveau driver, but I ran into a quite annoying problem on both
openSuSE Leap 42.2 (even with the latest kernel from the kernel stable
repository) and also with the latest Tumbleweed snapshot.
I don't have problems, running the nouveau driver if I don't have an
xorg.conf.d structure at all, but even with a very tiny structure the X
server won't start anymore, and I can't figure out, what I might be
missing here.
There are three scenarios:
1. No xorg.conf.d structure at all -> nouveau gets loaded, X is
starting.
Same behaviour with Leap 42.2 ad with Tumbleweed.
2. Tiny xorg.conf.d structure as shown below with a driver entry for
nouveau, i.e. Driver "nouveau" -> X server is not starting with an
entry "Unknown chipset: NV117" at the end of Xorg.0.log.
Same behaviour with Leap 42.2 ad with Tumbleweed.
3. Tiny xorg.conf.d structure as shown below without a driver entry for
nouveau -> X server is starting and one can logon via sddm, but a few
program starts later, the nouveau driver is crashing with errors like
"nouveau 0000:01:00.0: fifo: PBDMA0: 00040000 [PBENTRY] ch 15
[007e351000 X[1413]] subc 0 mthd 0000 data 00000000".
This happens with Leap 42.2 only, not with Tumbleweed - with the
exact same modules from kernel 4.8.9-1.
This is my xorg.conf.d structure:
# 00-keyboard.conf:
# .................
Section "InputClass"
Identifier "system-keyboard"
MatchIsKeyboard "on"
Option "XkbLayout" "de"
Option "XkbModel" "pc105"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection
# -----------------------------
# 50-device.conf:
# ...............
Section "Device"
Identifier "NVidia_GTX750"
Driver "nouveau"
EndSection
# -----------------------------
# 50-module.conf:
# ...............
Section "Module"
# Disable "glx"
EndSection
# -----------------------------
# 50-monitor.conf:
# ................
Section "Monitor"
Identifier "DELL_U2715H"
EndSection
# -----------------------------
# 50-screen.conf:
# ...............
Section "Screen"
Identifier "Screen_0"
Device "NVidia_GTX750"
Monitor "DELL_U2715H"
EndSection
# -----------------------------
# 99-serverlayout.conf:
# .....................
Section "ServerLayout"
Identifier "SingleHead_Layout"
Screen "Screen_0"
EndSection
# -----------------------------
Any idea, what might be going on here?
Thx!
Bye.
Michael.
--
Michael Hirmke
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi, I've got a bug in Cantata (available from the KDE:Extra repository)
since the beginning of october and I can't find where it comes from :
some icons are missing.
I opened a bug in bugzilla, but it was closed as I related it to the
openSUSE.org product. The person who closed it said it was maybe
"Tumbleweed specific" or related to Qt :
https://bugzilla.opensuse.org/show_bug.cgi?id=1007462
I also opened a bug in the git repository of the project, but it
appeared the developer tried to compile the software with Qt 5.7 and it
worked well (he uses Ubuntu). There are screenshots in the bug
discussion, so you can see exactly what the problem is:
https://github.com/CDrummond/cantata/issues/903
So my question is : would some of you be kind enough to install Cantata
from OBS and just tell me if all icons are displayed correctly, so I can
know if it's Tumbleweed related or very specific to me?
Thank you very much.
PAG
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Since a few days (perhaps weeks?) pidgin does not seem to play sounds
anymore when a new message arrives. I'm sure it used to do that.
According to the settings sounds are enabled. If I click on "Preview.."
for a given event there is some pulseaudio activity going on according
to strace. But in the end nothing is heard. The control-center audio
thing does play sound ("front left", "front right"), so I think parts of
the sound system do work properly.
Any idea why pidgin is silent?
List of packages that may be involved in the issue:
alsa-1.1.2-1.3.x86_64
alsa-oss-1.0.28-3.8.x86_64
alsa-oss-32bit-1.0.28-3.8.x86_64
alsa-plugins-1.1.1-1.5.x86_64
alsa-plugins-pulse-1.1.1-1.5.x86_64
alsa-plugins-pulse-32bit-1.1.1-1.5.x86_64
alsa-utils-1.1.2-1.3.x86_64
libtelepathy-glib0-0.24.1-2.3.x86_64
libtelepathy-glib0-debuginfo-0.24.1-2.3.x86_64
libtelepathy-logger3-0.8.2-2.1.x86_64
pulseaudio-9.0-2.2.x86_64
pulseaudio-bash-completion-9.0-2.2.x86_64
pulseaudio-module-bluetooth-9.0-2.2.x86_64
pulseaudio-module-gconf-9.0-2.2.x86_64
pulseaudio-module-lirc-9.0-2.2.x86_64
pulseaudio-module-x11-9.0-2.2.x86_64
pulseaudio-module-zeroconf-9.0-2.2.x86_64
pulseaudio-utils-32bit-9.0-2.2.x86_64
pulseaudio-utils-9.0-2.2.x86_64
speech-dispatcher-0.8.4-2.1.x86_64
speech-dispatcher-module-espeak-0.8.4-2.1.x86_64
telepathy-gabble-0.18.3-1.10.x86_64
telepathy-haze-0.8.0-5.5.x86_64
telepathy-idle-0.2.0-3.8.x86_64
telepathy-logger-0.8.2-2.1.x86_64
telepathy-mission-control-5.16.3-1.11.x86_64
telepathy-mission-control-plugin-goa-3.12.12-3.1.x86_64
telepathy-rakia-0.8.0-3.8.x86_64
telepathy-salut-0.8.1-7.9.x86_64
Olaf
Can someone tell me how to enable dhcp AND http_proxy during install/update of leap.
Mit freundlichen Grüßen
Joachim Reichelt
________________________________
Helmholtz-Zentrum für Infektionsforschung GmbH | Inhoffenstraße 7 | 38124 Braunschweig | www.helmholtz-hzi.de
Das HZI ist seit 2007 zertifiziertes Mitglied im "audit berufundfamilie"
Vorsitzende des Aufsichtsrates: MinDir’in Bärbel Brumme-Bothe, Bundesministerium für Bildung und Forschung
Stellvertreter: MinDirig Rüdiger Eichel, Niedersächsisches Ministerium für Wissenschaft und Kultur
Geschäftsführung: Prof. Dr. Dirk Heinz
Gesellschaft mit beschränkter Haftung (GmbH)
Sitz der Gesellschaft: Braunschweig
Handelsregister: Amtsgericht Braunschweig, HRB 477
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On 10/07/2016 05:27 AM, Matthias Brugger wrote:
>
>
>>>>>>
>>>>>> If you can bisect the kernel and point to a particular commit that
>>>>>> causes the increased packet loss, that would be very helpful. I
>>>>>> know of
>>>>>> no changes to any of the Realtek drivers that would cause these
>>>>>> kinds of
>>>>>> problems.
>>>>>>
>>>>>> Larry
>>>>>>
>>>>>
>>>>> Thanks Larry - I have some idea of bisecting software, but no idea in
>>>>> regards to
>>>>> the Tumbleweed. Where can I find the various commits/versions to test
>>>>> as part
>>>>> of the bisection?
>>>>
>>>> If openSUSE has a git repository for its kernels, I am not aware of its
>>>> location. Perhaps someone will come up with that information.
>>>>
>>>> You could clone the mainline repository from
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git. Every
>>>> change included in 4.7.X will be in that code. I would use the 4.7.5
>>>> configuration to build kernel 4.8 that is in that repo and test it. If
>>>> you still get the packet loss, then use the commands 'git bisect start
>>>> drivers/net/wireless/realtek/rtlwifi/', 'git bisect bad', and 'git
>>>> bisect good v4.6'. Change that last one to whatever version you
>>>> think is
>>>> good.
>>>>
>>>> That bisection will have roughly 5 steps to finish and should not take
>>>> too long, even with the full configuration used in distribution
>>>> kernels.
>>>>
>>>> Larry
>>>>
>>>>
>>>
>>> I keep getting errors when trying to star the git bisect.
>>>
>>> Here is what I get:
>>>
>>> git clone git://kernel.opensuse.org/kernel.git -b stable
>>> Cloning into 'kernel'...
>>> remote: Counting objects: 6374859, done.
>>> remote: fatal: inflateInit: out of memory (no message)
>>> remote: aborting due to possible repository corruption on the remote
>>> side.
>>> fatal: early EOF
>>> fatal: index-pack failed
>>>
>>> how can I get around this error, maybe a git option to not compress or
>>> some such thing?
>>>
>
> Strange, I don't get that error.
> You can try https://github.com/openSUSE/kernel.git instead.
>
> Regards,
> Matthias
>
>>> Thanks,
>>>
>>> --Moby
>>>
>>
>
Thanks Matthias, github.com/openSUSE/kernel.git worked just fine - I am
working on doing the bisect with it now.
--
--Moby
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi *,
on one of my machines (Lenovo T420 notebook) I have a problem with
plasmashell freezing often when a notification is shown. The
notification frame shows up, but no content and then the complete
desktop freezes. Killing and restarting plasmashell cures the problem
for a short time - til one of the the next notifications wants to
display something. It doesn't happen for all notifications, though.
Using tools like notify-send the problem can not be reproduced, but
notifications stemming from plasma-nm and plasma-workspace itself (like
the one for a removed plasmoid) always lead to the freeze.
The system originally was openSuSE Leap 42.2, but because of the problem
I upgraded step by step to
- the latest kernel from the kernel stable repo,
- the latest X server plus everyting from the X11:Xorg repo
- and the latest plasma workspace including everything from the
KDE:Framework5 repo.
The problem remained unchanged, though.
A few more facts:
- The X server is xf86-video-intel.
- Switching off the compositor doesn't help either.
- Everything worked with Leap 42.1
- No according entry in the journal or .xsession-errors* can be found.
- And a curiosity: After removing .config/plasmarc and restarting
plasmashell the problem vanishes for a few hours or even a day, before
it comes back.
- Logging off or restarting the machine doesn't help in case the
problems exists at that time.
In found a few bug reports for plasma freezes, but none of them seems to
fit exactly.
Is this a known problem?
Can I debug it and if so, how?
TIA.
Bye.
Michael.
--
Michael Hirmke
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
