Age | Commit message (Collapse) | Author | Files | Lines |
|
This is useful for debugging purposes, as it allows resolving the unique
D-Bus name into a PID and then into the calling program to display.
It makes it a lot easier to figure out which process is calling
PackageKit repeatedly.
|
|
This introduces no functional changes, but will make subsequent changes
easier.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
|
Like the `Packages` signal added a few commits previously, the
`UpdateDetails` signal is a plural version of the existing
`UpdateDetail` signal.
This has reduced the number of signals emitted during starting up
gnome-software from 632 `UpdateDetail` signals (for a corresponding
number of pending dnf updates) to 1 `UpdateDetails` signal.
The new signal is only used if the client sets the
`supports-plural-signals=true` hint on a transaction. Otherwise the old
`UpdateDetail` signal will be used. This means the new signal is
backwards-compatible.
If the hint is set, the new signal will be used in parallel with the old
one, with some operations or backends using the old signal, and some
using the new one. The content of the signals will not be duplicated
(i.e. if `UpdateDetails` is emitted for N updates, there will not also
be N `UpdateDetail` signal emissions in parallel).
The new signal is currently only implemented for the dnf backend. Other
backends can implement it at their leisure.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
|
This has reduced the number of signals emitted during starting up
gnome-software from 5711 `Package` signals, to 66 `Packages` signals
(one per transaction).
The signal is used only if the client sets the
`supports-plural-signals=true` hint on a transaction. Otherwise the old
`Package` signal will be used. This means the new signal is
backwards-compatible.
If the hint is set, the new signal will be used in parallel with the old
one, with some operations or backends using the old signal, and some
using the new one. The content of the signals will not be duplicated
(i.e. if `Packages` is emitted for N packages, there will not also be N
`Package` signal emissions in parallel).
The new signal is currently only implemented for the dnf backend. Other
backends can implement it at their leisure.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
|
|
|
|
|
`pk_client_init()` sets the default value to `G_MAXUINT` but the
`GParamSpec` setup didn’t also use that value.
This probably introduces no functional changes, but it makes the code
not contradict itself.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
|
That's currently to be able to set whether the method should be
interactive or not. The old functions call the methods as non-interactive.
Closes https://github.com/PackageKit/PackageKit/issues/504
|
|
To make it easier to know, in the code, that the user declined
the interaction on the task and react on it properly, rather than
checking a generic error code and the error message, which can
eventually change in the future.
|
|
The PkClient operates in two stages. The first is an "active" stage,
which makes one or more D-Bus calls. The second is a "passive" stage,
when it is waiting for the "Finished" D-Bus signal from the daemon.
The cancellation can come in any time. This change keeps the cancellation
up to the D-Bus calls during the first stage and actively stops the waiting
during the second stage.
As the GCancellable is cancelled in a different thread, and any D-Bus call
is also done and its result delivered in that thread default main context,
rather than in the main context when the PkClientState had been created,
the PkClientState is switched to a GObject descendant, to be able to benefit
from the GWeakRef, which can avoid use-after-free easily.
The GDBusProxy callbacks can be schedules in the middle of the object free,
thus the added callbacks also benefit from the GWeakRef usage.
All of this helps to better cover the PackageKit daemon disappear during
an ongoing call to it.
Closes https://github.com/PackageKit/PackageKit/issues/489
|
|
This can be used to distinguish the download size and whether the package
is already downloaded; use this in the dnf backend.
|
|
This can be used by backends, to provide an update severity for the package.
|
|
When cancelling a transaction, even if it fails, the associated transaction
still receives its async callback, thus also frees the 'state' structure.
That means, when the cancel fails, it should not free the 'state'.
This can be reproduced by a race condition between cancelling the operation
by the caller and delivery of the 'Cancel' D-Bus call. The call order is:
- the caller cancels the 'state->cancellable_client' cancellable
- the PkClient executed the 'Cancel' D-Bus method for this operation
- before the 'Cancel' D-Bus call is finished the operation finishes,
freeing the 'state' as well
- the 'Cancel' D-Bus method call is finished, possibly with an error like
"Transaction is already finished". As the 'state' is already freed, trying
to free it causes a use-after-free error and an application crash.
Signed-off-by: Richard Hughes <richard@hughsie.com>
|
|
The state::cancellable_client holds a passed-in cancellable variable,
which is reffed. This was never unreffed in the code.
Signed-off-by: Richard Hughes <richard@hughsie.com>
|
|
Two problems:
a) the 'state->cancellable' is not a new cancellable like in every other place;
b) the passed-in cancellable is supposed to be set into 'state->cancellable_client',
because on that cancellable is the signal disconnected, aka the disconnect
won't work for this function.
Signed-off-by: Richard Hughes <richard@hughsie.com>
|
|
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
|
If the property value doesn’t actually change, there’s no need to emit
the `notify` signal.
Note that I didn’t see this happening in practice — this fix is only as
a result of reading the code.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
|
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
|
If calling the `Cancel()` D-Bus method on a transaction fails, cancel
the client-side state anyway, to prevent the client from waiting forever
on a response which is unlikely to come.
Spotted in https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1118.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
|
Most of the time, when using a `GDBusProxy`, and the service you’re
talking to disappears, you’ll get notified — the async D-Bus call you’re
making will return an error. However, due to PackageKit’s design for
handling long-running operations, there are long periods between a
transaction being created, and emitting its `Finished` signal, when no
D-Bus calls are pending.
If the daemon crashes during one of these periods, there is currently no
way for the packagekit-glib2 client code to notice until it tries to
make another D-Bus call on the same `GDBusProxy` instance, and that
might never happen — it might wait for the `Finished` signal forever.
Avoid that by connecting to `notify::g-name-owner`, which is emitted on
`GDBusProxy` if the daemon crashes. It changes value from the unique
name of the service, to `NULL`. When that happens, abort the transaction
state in the client with an error.
This should stop gnome-software hanging indefinitely if PackageKit
crashes during a transaction. In particular, if this happens a few times
during consecutive refresh operations, gnome-software can eventually run
out of worker threads, and become unresponsive entirely. (See
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1118.) The same
will likely be true of other clients which use packagekit-glib2.
Equivalent changes don’t seem to be needed in `pk-control.c` (which also
uses `GDBusProxy`), because all of its D-Bus operations appear to
maintain no state outside of individual method calls.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
|
|
Avoid using full filename in comments as that can be different on
different arches if the build directory differs, leading to multilib
conflicts. Instead just use @basename@, which is always the same.
https://bugzilla.redhat.com/show_bug.cgi?id=1915259
|
|
|
|
|
|
This restores the original build of the GIR with automake.
|
|
|
|
|
|
requirement
|
|
With much help from Martin Blanchard <tchaik@gmx.com> too, thanks to all.
https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
|
|
|
|
|
|
Reuse debconf-socket in user runtime dir if it exists, as long as we
are not using debconf-kde or the current terminal, as socket-activation
does not work for the former, and we cannot use the current terminal
from the socket-activated helper...
|
|
This allows us to build an external client helper binary that
uses this function to build argv and evnp.
|
|
Extract pk_client_helper_start_with_socket() out of the function
pk_client_helper_start() so we can start a client helper for an
existing socket. This will allow us to get a socket from systemd
in a socket-activated service, for example.
|
|
This function enables code to check whether a client helper has
accepted connections.
A connection is considered active if one of its sources has not
been removed yet, even if it's just blocking waiting for data.
|
|
Stop dereferencing client_helper before validating it in public
functions.
|
|
|
|
This will fix compilation in system where only the "python3"
executable exists
|
|
This should fix /var/cache/PackageKit/"8.0"/ on RHEL 8.0 to not have
quotes in it.
|
|
Also, fd==0 is unlikely, but valid. Do the right thing in finalize().
|
|
|
|
- Fix buffer overflow writing nul character on the end of debconf reads
- Register IO callbacks on the thread main context - not the default context (broken in ac3b14be9e)
- Always accept incoming socket connections to avoid busy loop
- Fix loops from incorrect handling of various input error cases
- Close helper stdin when socket closes - was causing debconf UI to remain open and unresponsive
- Use standard IO priority to avoid busy loops
- Reliably clean up socket file on finalize
|
|
|
|
These could otherwise trigger on a deleted object.
|
|
In glib 2.56, g_object_ref() checks that we're assigning the return
value to a variable of the same type we're passing in.
|
|
This renames a few strings to match gnome-software terminology change in
https://gitlab.gnome.org/GNOME/gnome-software/commit/3bbf72c079ba6f4b864b7cd223e0cc5592380e2a
|
|
|
|
Don't try to debug print state->tid in cancelled callback as state may
have already been destroyed at that point.
https://bugzilla.gnome.org/show_bug.cgi?id=789438
|
|
This lets gnome-software handle distro upgrade and regular update
results differently.
|
|
|
|
|