Issues with PackageKit?

#21

Hello @bproj,
I was successful at building and running a flatpak of Deja-Dup by cloning their existing source at GitLab then building the flatpak using flatpak-builder in sudo mode, with the --install option set. I wasn’t sure if you had managed to get it running yet, and thought I would being inspired by @refi64. If you’re interested the process I followed was this…

  1. Clone the Deja-Dup git repo at Gitlab with the following command git clone https://gitlab.gnome.org/World/deja-dup.git in a directory of your choosing.
  2. Change into the deja-dup directory, then into the flatpak subdirectory
  3. Use the following command sudo flatpak-builder --install org.gnome.DejaDupDevel org.gnome.DejaDupDevel.yaml --force-clean

This will use the org.gnome.DejaDupDevel.yaml file to create and install a Deja-Dup flatpak app named org.gnome.DejaDupDevel. It will also create the directory of the same name. These commands are to be used in a terminal it is expected. The --force-clean option is only really necessary if you had done a previous build and had already the directory named as noted. I ran it after doing this process, but didn’t attempt a backup or restore (I do have an older Deja-Dup backup somewhere). Maybe I’ll hunt for those older DD backups I have and restore them, it might be nostalgic :stuck_out_tongue_closed_eyes:
[EDIT] Well that sucks, I can run DejaDup, but the app fails complaining it cannot understand the duplicity version information. This should be taken care of with the yaml file I thought where Duplicity is named a runtime dependency, or so I thought.

#22

PackageKit startup timing out also blocked realm join during initial boot :frowning:

#23

Thought I’d update everyone and due to changes up-stream a layered deja-dup now works.

#24

hi,

i have a similar problem with sb30 official beta. software center:

Error calling StartServiceByName for org.freedesktop.PackageKit: Timeout was reached

pkcon:

PackageKit could not be contacted: Error when calling StartServiceByName for org.freedesktop.PackageKit: timeout reached

when i open the software center, nothing loads. no access to the software-sources either. no updates (per software -center) possible. sometimes the search works after a long wait, sometimes not. i can only install and update flatpaks via the terminal.

is this “the fault” of an installed flatpak? are those applications that need “Freedesktop.org Application Platform version 18.08”? that would be vlc & spotify in my case (yes, i’m switching to lollypop anyway, but the totem/videos - development also seems to stand still).

ps: something like org.freedesktop.PackageKit is not installed (flatpak list).

mart

#25

My guess since pkcon and packagekit are part of the ostree commit, is that you have some issue with your commit. I would try rpm-ostree cleanup -m to cleanup the metadata. The flatpaks are pretty much isolated containers which have all the necessary bit’s inside so I doubt that is your problem. If you do have layered packages you could try a rpm-ostree reset to remove all mutations to see if that helps.

#26

thx @jakfrost but nope, did both, restart, same issues :frowning:

#27

Does journalctl -b -e -u packagekit show any errors?

#28

@refi64

hi refi, it only shows me the following at the bottom of the console (should there be logs?) :

logs begin at Wed 2019-04-03 17:22:07 CEST, end at Thu 2019-04-04 15:21:52 CEST. –
Apr 04 14:30:02 localhost.localdomain systemd[1]: Condition check resulted in PackageKit Daemon being skipped.

“daemon being skipped” ? & i cannot install anything from the flathub site (install) per software-manager. just tried it with gnome boxes. only possible via terminal.

ps: systemctl daemon-reload or something like that? or disable firewalld (currently “default” = “fedora workstation” zone) completely?

pps: but i tried:

systemctl restart packagekit.service

and

pkcon repair

… nothing.

ppps:

systemctl status packagekit.service -l 
packagekit.service - PackageKit Daemon
   Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static; vendor preset: disabled)
   Active: inactive (dead)

Apr 04 14:30:02 localhost.localdomain systemd[1]: Condition check resulted in PackageKit Daemon being skipped.
Apr 04 16:54:12 localhost.localdomain systemd[1]: Condition check resulted in PackageKit Daemon being skipped.
Apr 04 16:54:20 localhost.localdomain systemd[1]: Condition check resulted in PackageKit Daemon being skipped.
Apr 04 16:57:07 localhost.localdomain systemd[1]: Condition check resulted in PackageKit Daemon being skipped.
#29

Hmm so that’s normal-ish, PackageKit isn’t used for Flatpaks. The weirder issue would be the timeouts & Software bring empty.

Have you tried ignoring the PackageKit warnings and installing the Flathub repository file?

#30

i freshly installed the official beta yesterday. right after that i opened the terminal -> ostree upgrade & reboot & right after that i added the repos in the terminal:

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

flatpak remote-add flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo

after that the shell - extensions: “dash to panel” & “top right hot corner”. and after that i installed the flatpaks i needed - via terminal. so, nothing special/exotic. later i noticed that the software - center is non-functional.

now i downloaded the repo linked by you and the software - center shows me at least that flathub.flatpakrepo is installed. but if i go to the software - center for “updates” or “categories”, nothing is shown/loaded - except the error message in “updates”:

error calling startservicebyname for org.freedesktop.packagekit: timeout was reached

ps: the only “exotic” thing i did, was to install all required flatpaks at the same time. i wanted to take advantage of the new terminal and the new “riders” (i hope this is the exact english translation) or (better) “tabs”.

from some flatpak - apps i got the message that xy was already installed (from another flatpak app in another tab/rider). that was the only thing i noticed. after that i did a

flatpak remove --unused

that was all. now, every app works the way it should. but the software - center …

ps: it seems, i’m not the only one with this problem: https://invidio.us/watch?v=seeOs05tDMA . “jiraya tira” -> youtube (not reddit) comment to the video. additional info journalctl -b :

-- Logs begin at Wed 2019-04-03 17:22:07 CEST, end at Fri 2019-04-05 08:29:05 CEST. --
Apr 05 07:38:24 localhost kernel: Linux version 5.0.5-300.fc30.x86_64 (mockbuild@bkernel03.phx2.fedoraproject.org) (gcc version 9.0.1 20190227 (Red Hat 9.0.1-0.8) (GCC))>
Apr 05 07:38:24 localhost kernel: Command line: BOOT_IMAGE=/ostree/fedora-workstation-235651f78d8469c4fd3115f5a77a8f702043a8aad9f550a8269d4d57d32fc75f/vmlinuz-5.0.5-300.>
Apr 05 07:38:24 localhost kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Apr 05 07:38:24 localhost kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Apr 05 07:38:24 localhost kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Apr 05 07:38:24 localhost kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
Apr 05 07:38:24 localhost kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Apr 05 07:38:24 localhost kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Apr 05 07:38:24 localhost kernel: x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
Apr 05 07:38:24 localhost kernel: x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
Apr 05 07:38:24 localhost kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
Apr 05 07:38:24 localhost kernel: BIOS-provided physical RAM map:
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reserved
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000009dfff] usable
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x000000000009e000-0x00000000000fffff] reserved
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000073786fff] usable
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x0000000073787000-0x0000000073787fff] ACPI NVS
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x0000000073788000-0x0000000073788fff] reserved
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x0000000073789000-0x0000000075387fff] usable
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x0000000075388000-0x0000000075c87fff] reserved
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x0000000075c88000-0x000000008be9dfff] usable
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x000000008be9e000-0x000000008c88dfff] reserved
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x000000008c88e000-0x000000008cf7dfff] ACPI NVS
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x000000008cf7e000-0x000000008cffdfff] ACPI data
Apr 05 07:38:24 localhost kernel: BIOS-e820: [mem 0x000000008cffe000-0x000000008cffefff] usable