12:20 p.m.
How to I can disable packagekid to download update?
I do not use these packages downloaded uselessly from packagekit into
/var/cache/PackageKit/*/*/updates/... because I run sometimes when I
want and can, after, reboot, "sudo dnf update".
Unfortunately this command (dnf) do not use the rpm files download from
PackageKit but it downloads them again ... Sigh!
Many thanks
--
Dario Lesca
(inviato dal mio Linux Fedora 27 Workstation)
12:54 p.m.
Dario Lesca wrote:
How to I can disable packagekid to download update?
I do not use these packages downloaded uselessly from packagekit into
/var/cache/PackageKit/*/*/updates/... because I run sometimes when I
want and can, after, reboot, "sudo dnf update".
Unfortunately this command (dnf) do not use the rpm files download from
PackageKit but it downloads them again ... Sigh!
You can disable downloading of updates via gsettings:
gsettings set org.gnome.software download-updates false
Doing this prevents rpms from accumulating, but you still end up with
several hundred megabytes of repo metadata (which isn't ever cleaned
up for old releases, so it builds up). I just checked and there was
800M on my system, with 147M for f26, which I have am not yet running.
When I do upgrade, it will be via dnf system-upgrade, so the
PackageKit data does nothing for me.
Alternatively, you can remove PackageKit and gnome-software if you
don't use them:
sudo dnf remove PackageKit* gnome-software
You'll have to manually clean up the cache dir afterward. This is
filed in the fedora and freedesktop.org bug trackers:
https://bugzilla.redhat.com/1306992
https://bugs.freedesktop.org/80053
Both tickets have been around for a long time without any fixes,
unfortunately.
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The worst thing about history is that every time it repeats itself,
the price goes up.
-- Pillar
1:58 p.m.
Not DONTCARE, more "really busy with other stuff". If somebody else figures
out a good way to invalidate the cache (probably done in libdnf), I'm happy
to review patches and build packages. It can't *all* be on my shoulders,
right? Richard
On 2 Dec 2017 19:00, "Joe Zeff" <joe(a)zeff.us> wrote:
On 12/02/2017 10:54 AM, Todd Zullinger wrote:
> Both tickets have been around for a long time without any fixes,
> unfortunately.
>
Judging by the lack of response on some bugzillas I've entered, the
appropriate resolution would be Closed, DON'TCARE.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
2:12 p.m.
On 12/02/2017 11:58 AM, Richard Hughes wrote:
Not DONTCARE, more "really busy with other stuff". If
somebody else
figures out a good way to invalidate the cache (probably done in
libdnf), I'm happy to review patches and build packages. It can't *all*
be on my shoulders, right? Richard
That's good to know. However, over the years I've had bug reports that
were never followed up or assigned, with the only comment after the
original report being an announcement that it was being closed at EOL
for that version. AFAICT, nobody even looked at them, and the closing
was simply an autobot.
6:21 p.m.
Joe Zeff wrote:
On 12/02/2017 11:58 AM, Richard Hughes wrote:
> Not DONTCARE, more "really busy with other stuff". If somebody else
> figures out a good way to invalidate the cache (probably done in
> libdnf), I'm happy to review patches and build packages. It can't
> *all* be on my shoulders, right? Richard
That's good to know. However, over the years I've had bug reports
that were never followed up or assigned, with the only comment after
the original report being an announcement that it was being closed
at EOL for that version. AFAICT, nobody even looked at them, and
the closing was simply an autobot.
While I'm sure some bugs are not viewed by any maintainers, I'd wager
that's far fewer than thoss which are viewed and the maintainer simply
lacks enough time to do anything with it. There's no way to see if a
bug was viewed, so as a reporter we can only guess. It would be ideal
if all bug reports led to fixes, but that's not likely.
With this particular PackageKit issue, I think that it might be
lingering for longer because the users most affected are less likely
to be folks that would dig into the problem and submit patches to the
appropriate component (as Richard said, the place for a fix might be
in libdnf). I know personally, I don't make use of PackageKit and
Gnome Software, so I "solve" this for myself by removing those
packages rather than trying to fix it.
It does seem like as long as it's been around that someone who cared
might have submitted a patch. I've long told people on projects I
contribute to that complaints/bug reports/suggestions in unified diff
format are the best. ;)
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Whenever you find yourself on the side of the majority, it is time to
pause and reflect.
-- Mark Twain
6:57 p.m.
On Sat, 2 Dec 2017 19:21:55 -0500
Todd Zullinger wrote:
While I'm sure some bugs are not viewed by any maintainers,
I'd wager
that's far fewer than thoss which are viewed and the maintainer simply
lacks enough time to do anything with it.
On the other hand there are the bugs which are on the federal register
of historic bugs, like this one :-).
https://bugzilla.redhat.com/show_bug.cgi?id=451562
8:54 p.m.
Tom Horsley wrote:
On Sat, 2 Dec 2017 19:21:55 -0500
Todd Zullinger wrote:
> While I'm sure some bugs are not viewed by any maintainers, I'd wager
> that's far fewer than thoss which are viewed and the maintainer simply
> lacks enough time to do anything with it.
On the other hand there are the bugs which are on the federal register
of historic bugs, like this one :-).
https://bugzilla.redhat.com/show_bug.cgi?id=451562
Heh, only 9 and a half years? That's just a baby. ;)
One I've always remembered was #998¹, to check package signatures in
the installer. It's been closed for a few years now, but it had the
alias 'oldest-bug-evar' for a while. But that wasn't ignored. It was
just not something anyone could agree on a proper fix, for various
reasons.
There are certainly plenty of bugs open for frustratingly long times,
I'd never argue against that. I've got some open for the git package
which are fairly old, so I've felt this from both sides.
But hey, at least this isn't Atlassian. I've watched bugs for their
commercial products rot away for years and years, over trivial things
that paying customers want.
¹ https://bugzilla.redhat.com/show_bug.cgi?id=998
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are young and you drink a great deal it will spoil your health,
slow your mind, make you fat - in other words, turn you into an adult.
-- P.J. O'Rourke
3:18 a.m.
New subject: F27: how to disable (or remove) packagekit to download updates
Il giorno sab, 02/12/2017 alle 19.21 -0500, Todd Zullinger ha scritto:
I don't make use of PackageKit and
Gnome Software, so I "solve" this for myself by removing those
packages rather than trying to fix it.
This seem is a finally solution.
Why not do it for all?
Cinnamon o other spin do not use PackageKit and gnome-software, I think
that Fedora Workstation (Gnome) can do it too
There are for example dnfdragora that can do the gnome-software and
update system jobs
Thanks
--
Dario Lesca
(inviato dal mio Linux Fedora 27 Workstation)
4:52 a.m.
New subject: F27: how to disable (or remove) packagekit to download updates
On Sun, 2017-12-03 at 10:18 +0100, Dario Lesca wrote:
Il giorno sab, 02/12/2017 alle 19.21 -0500, Todd Zullinger ha
scritto:
> I don't make use of PackageKit and
> Gnome Software, so I "solve" this for myself by removing those
> packages rather than trying to fix it.
This seem is a finally solution.
Why not do it for all?
Cinnamon o other spin do not use PackageKit and gnome-software, I think
that Fedora Workstation (Gnome) can do it too
There are for example dnfdragora that can do the gnome-software and
update system jobs.
I only ever use dnf from the command line, so removing PackageKit and
the associated cache just gave me back about a GB I didn't even know
was there.
poc
2:17 p.m.
On Sat, 2 Dec 2017 13:54:35 -0500
Todd Zullinger <tmz(a)pobox.com> wrote:
Dario Lesca wrote:
> How to I can disable packagekid to download update?
You can disable downloading of updates via gsettings:
gsettings set org.gnome.software download-updates false
Doing this prevents rpms from accumulating, but you still end up with
several hundred megabytes of repo metadata (which isn't ever cleaned
up for old releases, so it builds up). I just checked and there was
800M on my system, with 147M for f26, which I have am not yet
running. When I do upgrade, it will be via dnf system-upgrade, so the
PackageKit data does nothing for me.
Alternatively, you can remove PackageKit and gnome-software if you
don't use them:
sudo dnf remove PackageKit* gnome-software
Another alternative for disabling PackageKit is to move the file
org.freedesktop.PackageKit.service
to
org.freedesktop.PackageKit.service.bak
in the /usr/share/dbus-1/system-services/ directory.
You'll also have to move the file
kde-org.freedesktop.PackageKit.service
to
kde-org.freedesktop.PackageKit.service.bak
in the /usr/share/dbus-1/services directory if you have kde installed.
This will have to be done every time PackageKit is updated, but that
isn't all that often.
I keep PackageKit around because even though I like to do my updates
from the command line in a virtual console, I keep Gnome around, and it
is an integral part of Gnome.
2:35 p.m.
On 12/02/2017 12:17 PM, stan wrote:
You'll also have to move the file
kde-org.freedesktop.PackageKit.service
to
kde-org.freedesktop.PackageKit.service.bak
in the /usr/share/dbus-1/services directory if you have kde installed.
This will have to be done every time PackageKit is updated, but that
isn't all that often.
Wouldn't it be easier to mask the service and be done with it? Or, if
that prevents it from running when you need it, disable it.
7:02 p.m.
stan wrote:
On Sat, 2 Dec 2017 13:54:35 -0500
Todd Zullinger <tmz(a)pobox.com> wrote:
> Dario Lesca wrote:
> > How to I can disable packagekid to download update?
> You can disable downloading of updates via gsettings:
>
> gsettings set org.gnome.software download-updates false
>
> Doing this prevents rpms from accumulating, but you still end up with
> several hundred megabytes of repo metadata (which isn't ever cleaned
> up for old releases, so it builds up). I just checked and there was
> 800M on my system, with 147M for f26, which I have am not yet
> running. When I do upgrade, it will be via dnf system-upgrade, so the
> PackageKit data does nothing for me.
>
> Alternatively, you can remove PackageKit and gnome-software if you
> don't use them:
>
> sudo dnf remove PackageKit* gnome-software
Another alternative for disabling PackageKit
The poster asked how to disable "download updates", not how to disable
PackageKit completely (a very different question and solution)
-- Rex
2328
days inactive
2330
days old
13 comments
8 participants
participants (8)
-
Dario Lesca -
Joe Zeff -
Patrick O'Callaghan -
Rex Dieter -
Richard Hughes -
stan -
Todd Zullinger -
Tom Horsley