In data mercoledì 28 febbraio 2024 10:24:00 CET, Stakanov via openSUSE Users ha scritto:

In data mercoledì 28 febbraio 2024 10:03:48 CET, Masaru Nomiya ha scritto:

...

Hello,

In the Message;

Subject : strange problem with BT in KDE Plasma: bluez claims "file

transfer succeded" but does not save, now does not even connect. Seems broken. Message-ID : <2741195.8fWqujpI5n@silversurfer.fritz.box>

Date & Time: Wed, 28 Feb 2024 09:11:59 +0100

[S] == Stakanov via openSUSE Users has written:

S> Connecting from my smartphone with BT to bluez, I can send files S> with "share",the BT bluez of my PC says transfer running, transfer S> succeeded, but the itclaims "cannot save files" and now file is S> saved indeed.

S> I have no explanation, the directory is the home directory of the user with a S> dedicated BT download directory, I checked permissions and did chmod on it to S> make sure all files and the directory have the correct permissions.

S> That was yesterday, now it is even worse (yesterday I detached and reattached S> the BT dongle) so it shows connected, even the battery remaining on the S> smartphone but.... the sending process remains 0 and no notice in KDE appears. S> After a while it interrupts. No idea why it did not save yesterday, why it S> does not receive the files today...... [...]

Is the Bluetooth OBEX service running?

If not, how about this?

$ systemctl --user start dbus-org.bluez.obex.service

Kind Regards.

--- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Companies have come to view generative AI as a kind of monster that

must be fed at all costs―even if it isn’t always clear what

exactly

...

that data is needed for or what those future AI systems might

end

up

...

doing."

-- Generative AI Is Making Companies Even More Thirsty for Your Data

--

normally I had it activated, but the command went through right to the prompt so it should be running now.

Is this (when done as the user) permanently as activation? How can I force it to be activated permanently on this system for all users?

Thank you. I checked but it still fails. I also installed the ftp obex from yast, but makes no difference.

entropy@silversurfer:~> systemctl --type=service --state=running UNIT LOAD ACTIVE SUB DESCRIPTION apcupsd.service loaded active running APC UPS Power Control Daemon for Linux auditd.service loaded active running Security Auditing Service avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack bluetooth.service loaded active running Bluetooth service chronyd.service loaded active running NTP client/server cron.service loaded active running Command Scheduler cups-browsed.service loaded active running Make remote CUPS printers available locally cups.service loaded active running CUPS Scheduler dbus.service loaded active running D-Bus System Message Bus display-manager.service loaded active running X Display Manager firewalld.service loaded active running firewalld - dynamic firewall daemon getty@tty1.service loaded active running Getty on tty1 getty@tty3.service loaded active running Getty on tty3 getty@tty4.service loaded active running Getty on tty4 getty@tty5.service loaded active running Getty on tty5 getty@tty6.service loaded active running Getty on tty6 irqbalance.service loaded active running irqbalance daemon kvm_stat.service loaded active running Service that logs KVM kernel module trace events mcelog.service loaded active running Machine Check Exception Logging Daemon mdmonitor.service loaded active running MD array monitor ModemManager.service loaded active running Modem Manager NetworkManager.service loaded active running Network Manager nscd.service loaded active running Name Service Cache Daemon polkit.service loaded active running Authorization Manager postfix.service loaded active running Postfix Mail Transport Agent power-profiles-daemon.service loaded active running Power Profiles daemon rtkit-daemon.service loaded active running RealtimeKit Scheduling Policy Service smartd.service loaded active running Self Monitoring and Reporting Technology (SMART) Daemon sshd.service loaded active running OpenSSH Daemon systemd-journald.service loaded active running Journal Service systemd-logind.service loaded active running User Login Management systemd-machined.service loaded active running Virtual Machine and Container Registration Service systemd-udevd.service loaded active running Rule-based Manager for Device Events and Files udisks2.service loaded active running Disk Manager unbound.service loaded active running Unbound recursive Domain Name Server upower.service loaded active running Daemon for power management user@1000.service loaded active running User Manager for UID 1000 user@1002.service loaded active running User Manager for UID 1002 virtnetworkd.service loaded active running libvirt network daemon virtnodedevd.service loaded active running libvirt nodedev daemon virtqemud.service loaded active running libvirt QEMU daemon virtstoraged.service loaded active running libvirt storage daemon LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 42 loaded units listed. I do not see obex running. When I ask for status it gives: entropy@silversurfer:~> systemctl status dbus-org.bluez.obex.service Unit dbus-org.bluez.obex.service could not be found.

On 2024-02-28 03:36, Stakanov via openSUSE Users wrote:

I do not see obex running. When I ask for status it gives:

entropy@silversurfer:~> systemctl status dbus-org.bluez.obex.service Unit dbus-org.bluez.obex.service could not be found.

This means the service isn't even installed. It will be installed as part of some package that you don't yet have on your system. I don't use this service so I'm not sure which package the systemctl service file will be in. Try installing package bluez-obexd (just a guess).

On 2024-02-28 05:18, Andrei Borzenkov wrote:

On Wed, Feb 28, 2024 at 2:09 PM Darryl Gregorash wrote:

...

On 2024-02-28 03:36, Stakanov via openSUSE Users wrote:

...

I do not see obex running. When I ask for status it gives:

entropy@silversurfer:~> systemctl status dbus-org.bluez.obex.service Unit dbus-org.bluez.obex.service could not be found.

This means the service isn't even installed.

Or that it is user service. Possibly. However...

I installed bluez.obexd to check this out. There is a user service called obex.service: [Unit] Description=Bluetooth OBEX service [Service] Type=dbus BusName=org.bluez.obex ExecStart=/usr/lib/bluetooth/obexd [Install] Alias=dbus-org.bluez.obex.service and a D-Bus service file called org.bluez.obex.service which is found in /usr/share/dbus-1/services. Here is that file: [D-BUS Service] Name=org.bluez.obex Exec=/bin/false SystemdService=dbus-org.bluez.obex.service I know nothing about bluetooth or these dbus services, so by this point, I haven't got a clue what is going on. Time for a google search, "dbus-org.bluez.obex.service not found". From https://bugs.archlinux.org/task/45816, try this (as root): systemctl --global enable obex. Because of that Alias line in obex.service, this is where our missing file is born: # systemctl --global enable obex.service Created symlink /etc/systemd/user/dbus-org.bluez.obex.service → /usr/lib/systemd/user/obex.service Now the service is enabled for every user on the system. I'm not certain, but I think it should also be started whenever a user logs in -- if not, then certainly whenever a bluetooth call is made on the dbus.

In data mercoledì 28 febbraio 2024 14:57:37 CET, Darryl Gregorash ha scritto:

...

On 2024-02-28 05:18, Andrei Borzenkov wrote:

...

On Wed, Feb 28, 2024 at 2:09 PM Darryl Gregorash wrote:

...

On 2024-02-28 03:36, Stakanov via openSUSE Users wrote:

...

I do not see obex running. When I ask for status it gives:

entropy@silversurfer:~> systemctl status dbus-org.bluez.obex.service Unit dbus-org.bluez.obex.service could not be found.

This means the service isn't even installed.

Or that it is user service.

Possibly. However...

I installed bluez.obexd to check this out. There is a user service called obex.service:

[Unit] Description=Bluetooth OBEX service

[Service] Type=dbus BusName=org.bluez.obex ExecStart=/usr/lib/bluetooth/obexd

[Install] Alias=dbus-org.bluez.obex.service

and a D-Bus service file called org.bluez.obex.service which is found in /usr/share/dbus-1/services. Here is that file:

[D-BUS Service] Name=org.bluez.obex Exec=/bin/false SystemdService=dbus-org.bluez.obex.service

I know nothing about bluetooth or these dbus services, so by this point, I haven't got a clue what is going on. Time for a google search, "dbus-org.bluez.obex.service not found".

...

From https://bugs.archlinux.org/task/45816, try this (as root): systemctl --global enable obex.

Because of that Alias line in obex.service, this is where our missing file is born: # systemctl --global enable obex.service Created symlink /etc/systemd/user/dbus-org.bluez.obex.service → /usr/lib/systemd/user/obex.service

Now the service is enabled for every user on the system. I'm not certain, but I think it should also be started whenever a user logs in -- if not, then certainly whenever a bluetooth call is made on the dbus.

ntropy@silversurfer:~> sudo systemctl --global enable obex [sudo] password di root: Created symlink /etc/systemd/user/dbus-org.bluez.obex.service → /usr/lib/ systemd/user/obex.service.

But when I do status:

entropy@silversurfer:~> systemctl status dbus-org.bluez.obex.service Unit dbus-org.bluez.obex.service could not be found.

hmmmmm, so maybe I have to reboot first. Not really. Notice where those files are located -- this is a user service, so you need to use the --user flag with systemctl (don't run

On 2024-02-28 08:10, Stakanov via openSUSE Users wrote: this as root): systemctl --user status dbus-org.bluez.obex.service

On 2024-02-28 13:51, Stakanov via openSUSE Users wrote:

In data mercoledì 28 febbraio 2024 16:03:04 CET, Darryl Gregorash ha scritto:

...

systemctl --user status dbus-org.bluez.obex.service

Yes thank you. There is still an issue that it complains the UUID is already registered, but I do not know how much of importance this might have. If you generated a billion UUIDs per second, you could expect to see 1 UUID collision (duplication) every 86 years.

Try stopping and then restarting the service. It the problem still exists, try rebooting, or at the very least, logging out then back in. You may need to examine the system log to find out if there is still UUID duplication. If there is, it should probably be reported as a bug -- at the very least, raise the issue in the openSUSE forums.

But it is running now. What puzzles me that they make this such a hurdle for a GDI. One would expect bluetooth to be useable or at least some advice in the install notice (which I do not recall). Will have to do this also on my laptop, thank you for the help given. Much appreciated.

Absolutely. Average computer users today do not want to have to spend a lot of time figuring out why something doesn't work, and searching for solutions can take a great deal of time. If there is a simple solution to such a problem (as there is here), it should be taken care of at installation time. In this case, simply adding the command systemctl --global enable obex to a post-install script for the bluez-obexd package will do just that. This is definitely a bug which should be reported -- though I do not know what good that might have. Earlier I mentioned I got this information from a bug report on the archlinux website. That bug actually dates from summer of 2015, and user intervention is still needed to get the thing to work.

In data giovedì 29 febbraio 2024 03:05:42 CET, Masaru Nomiya ha scritto:

Hello,

In the Message;

Subject : Re: strange problem with BT in KDE Plasma: bluez claims "file transfer succeded" but does not save, now does not even connect. Seems broken. Message-ID : <2790254.28gdL38g8h@silversurfer.fritz.box> Date & Time: Wed, 28 Feb 2024 20:51:14 +0100

[...]

It's a well-known bluez's bug.

It may be solved by using a different version of bluez, but in the meantime, it is better to report it to the upstream.

Best Regards.

--- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━ You both were of great help. Thank you very much. I will try to set up the respective reports. l Have a great day, both of you.

On 2024-02-28 03:24, Stakanov via openSUSE Users wrote:

...

Is the Bluetooth OBEX service running?

If not, how about this?

$ systemctl --user start dbus-org.bluez.obex.service

normally I had it activated, but the command went through right to the prompt so it should be running now.

Is this (when done as the user) permanently as activation? How can I force it to be activated permanently on this system for all users?

As root, run this: systemctl enable dbus-org.bluez.obex.service Then the service will be started every time the system boots. Note that you may have to modify some user's details for it to work for everyone. For example, you may need to add everyone to some group to give access to system files. I don't use this, so I can't do more than mention it so you are aware of the possibility.

On 2024-02-28 05:51, Stakanov via openSUSE Users wrote:

In data mercoledì 28 febbraio 2024 11:54:32 CET, Darryl Gregorash ha scritto:

...

As root, run this:

systemctl enable dbus-org.bluez.obex.service

Then the service will be started every time the system boots.

Note that you may have to modify some user's details for it to work for everyone. For example, you may need to add everyone to some group to give access to system files. I don't use this, so I can't do more than mention it so you are aware of the possibility.

entropy@silversurfer:~> sudo systemctl enable dbus-org.bluez.obex.service Failed to enable unit: Unit file dbus-org.bluez.obex.service does not exist. OK, time to gather all of this into one post. First let me apologize for not doing that right at the beginning. I also made a couple of errors that are corrected in this post.

The service dbus-org.bluez.obex.service does not even exist until you first enable obex.service, which is in the package bluez-obexd. So make sure that package is installed, then run (as root): # systemctl --global enable obex Created symlink /etc/systemd/user/dbus-org.bluez.obex.service → /usr/lib/systemd/user/obex.service Now the service file we need does exist. It is a _user_ service, so I was wrong when I said to enable it from the root account. It's already located in /etc/systemd/user, which means it is already enabled -- to there is no need to enable it. Let's get its status to check this. Run (as you, or any ordinary user): hadron:~> systemctl --user status dbus-org.bluez.obex.service ○ obex.service - Bluetooth OBEX service Loaded: loaded (/usr/lib/systemd/user/obex.service; enabled; vendor preset: disabled) Active: inactive (dead) Yes, it is enabled, so (I think/hope) it should be started every time you log into your user account. If it is not, simply create a script to start the service and place it in some convenient place, eg somewhere in your home directory (personally I'd use ~/bin), then add it to System Settings/Startup and Shutdown/Autostart. Again, my apologies for all the confusion. I've verified all the above except for my speculation about the service starting automatically when you log in -- which I can't do since I don't use bluetooth at all.

Hello, In the Message; Subject : Re: strange problem with BT in KDE Plasma: bluez claims "file transfer succeded" but does not save, now does not even connect. Seems broken. Message-ID : <9672f21e-15ee-432d-84f0-85d0ba8de4fe@gmail.com> Date & Time: Sun, 3 Mar 2024 09:35:05 +0300 [AB] == Andrei Borzenkov has written: AB> On 03.03.2024 02:01, Darryl Gregorash wrote: DG>> Yes, it is enabled, so (I think/hope) it should be started every DG>> time you log into your user account. AB> It will be auto-started by D-Bus when someone tries to connect to the AB> corresponding D-Bus endpoint. I don't have a device that requires obex, so I can't be sure, but I have figured out the cause of the glitch that Stakanov and I, or rather all users of sddm on Tumbleweed, encountered last night. The cause is that dbus does not start automatically when logging in with sddm. However, this problem does not occur with gdm or lightdm. So I thought I would report this here, but an update this morning fixed the problem, with the following results; $ ps aux | grep dbus | grep sddm sddm 2099 0.0 0.0 8332 1936 ? S 17:13 0:00 /usr/bin/dbus-launch.x11 --autolaunch a7ca534f07ff4a188c4f4ee6e146552b --binary-syntax --close-stderr sddm 2100 0.0 0.0 8444 2452 ? Ss 17:13 0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session Stakanov, you got the problem fixed today, how's that? Although I say it is resolved, I don't like the sound quality of the playback sound. So I installed sddm-greeter-qt5-0.21.0, sddm-0.21.0, and sddm-branding-openSUSE-0.21.0 from KDE:Frameworks5/openSUSE_Factory repository. As a result, the breadth and depth of the sound is much improved, and I feel very happy now. Best Regards & Good Night. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Distinguish between what is meaningful to me and what is meaningless, and forget what is meaningless to me. This is where individuality comes into play. This is a function that computer cannot perform." -- Shigehiko Toyama (in Japanes) --