Is dnf no longer using delta rpms? I updated two computers this morning and it looks like both were 100% rpms ...
Without that feature I have to be careful not to do large upgrades during "prime time" on my Viasat account as I just did on the second one. :-(
Bob
Bob,
When I was under a FAP, I used to do a trick. I would mount /var/cache/dnf via nfs from my main machine on the others I was updating and then change /etc/yum.conf (keepcache to 1) and that way generally the first node would fill the cache, and then the 2nd node would reuse the data downloaded by the first machine (assuming both are the same fedora version). You just have to make sure to do one and let it finish then after it is done move on to the second.
Roger
On Mon, Aug 21, 2017 at 10:27 AM, Bob Goodwin bobgoodwin@fastmail.us wrote:
Is dnf no longer using delta rpms? I updated two computers this morning and it looks like both were 100% rpms ...
Without that feature I have to be careful not to do large upgrades during "prime time" on my Viasat account as I just did on the second one. :-(
Bob
-- Bob Goodwin - Zuni, Virginia, USA http://www.qrz.com/db/W2BOD box10 FEDORA-26/64bit LINUX XFCE Fastmail POP3 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 08/21/17 19:24, Roger Heflin wrote:
I would mount /var/cache/dnf via nfs from my main machine on the others I was updating and then change /etc/yum.conf (keepcache to 1) and that way generally the first node would fill the cache, and then the 2nd node would reuse the data downloaded by the first machine (assuming both are the same fedora version). You just have to make sure to do one and let it finish then after it is done move on to the second.
Roger
+
I have three computers set up to look and work the same, however this one is booted every morning, the others not so often. Yesterday's update was unusually large since it had not been done for a week. There's also a portable configured similarly but rarely used. With time they tend to squire different applications making each a little different so I'm not sure how well a local collection of updates would work. I thought about it at times but usually just drop the idea.
It's simple enough to just do the updates during the "free" time from midnight to five and that's what I usually do. When my usage runs low for the month I sometimes elect to run an update during the day. That's what happened yesterday, it said it was a 374 MB download, I thought well it will reduce to much less with drpm's, and was surprised when I saw none.
It's not a disaster, just a surprise and an annoyance. I figure I can use ~800MB a day and stay within limits. Had I realized dnf was not using the delta rpms I might have waited.
I don't see a "drpms" directory in the fedora 26 "updates" directory. It's still present for f25 and f27. I haven't seen any notices about that, so it might be a failure. I'm asking in the #fedora IRC channel. I'll file a bug later if needed.
On 08/21/17 20:06, Gordon Messmer wrote:
I don't see a "drpms" directory in the fedora 26 "updates" directory. It's still present for f25 and f27. I haven't seen any notices about that, so it might be a failure. I'm asking in the #fedora IRC channel. I'll file a bug later if needed. _______
Thank you Gordon, I appreciate your interest and response to my inquiry.
On 08/22/17 15:25, Gordon Messmer wrote:
The "drpms" directory is back, today.
+ Well then it was probably missing for just a day or two and it happened when I cared about usage.
I ran dnf upgrades this morning as usual but I needed no updates.
# dnf upgrade Last metadata expiration check: 0:13:52 ago on Tue Aug 22 03:03:54 2017. Dependencies resolved. Nothing to do. Complete!
I'll see what happens next update.
On 08/22/17 15:25, Gordon Messmer wrote:
The "drpms" directory is back, today.
. Can I determine if "drpms" are being provided before actually downloading them? If so how?
Also the following notice came up this morning. I assume this will wait until the dependency becomes available?
# dnf upgrade Last metadata expiration check: 0:00:00 ago on Wed Aug 23 04:43:05 2017. Dependencies resolved.
Problem: cannot install the best update candidate for package firefox-55.0.1-1.fc26.x86_64 - nothing provides nspr >= 4.16.0 needed by firefox-55.0.2-1.fc26.x86_64
On 08/23/2017 08:40 PM, Bob Goodwin wrote:
# dnf upgrade Last metadata expiration check: 0:00:00 ago on Wed Aug 23 04:43:05 2017. Dependencies resolved.
Problem: cannot install the best update candidate for package firefox-55.0.1-1.fc26.x86_64
- nothing provides nspr >= 4.16.0 needed by firefox-55.0.2-1.fc26.x86_64
nspr is still in updates-testing. If you want you can run "dnf --enablerepo updates-testing update firefox"
On 08/23/17 09:27, Ed Greshko wrote:
Problem: cannot install the best update candidate for package firefox-55.0.1-1.fc26.x86_64
- nothing provides nspr >= 4.16.0 needed by firefox-55.0.2-1.fc26.x86_64
nspr is still in updates-testing. If you want you can run "dnf --enablerepo updates-testing update firefox"
. Ok, I guess it can wait.
Thanks
On 23/08/17 14:27, Ed Greshko wrote:
On 08/23/2017 08:40 PM, Bob Goodwin wrote:
# dnf upgrade Last metadata expiration check: 0:00:00 ago on Wed Aug 23 04:43:05 2017. Dependencies resolved.
Problem: cannot install the best update candidate for package firefox-55.0.1-1.fc26.x86_64
- nothing provides nspr >= 4.16.0 needed by firefox-55.0.2-1.fc26.x86_64
nspr is still in updates-testing. If you want you can run "dnf --enablerepo updates-testing update firefox"
Thank you! I have just done that. Because dnf wasn't able to update Firefox to the best version it removed it instead! I assume this is a result of the combination --best --allowerasing which I generally use. I've never had it just remove things completely leaving no version installed though :(
Regards, Chris R.
On Thu, 2017-08-24 at 09:03 +0100, Christopher Ross wrote:
On 23/08/17 14:27, Ed Greshko wrote:
On 08/23/2017 08:40 PM, Bob Goodwin wrote:
# dnf upgrade Last metadata expiration check: 0:00:00 ago on Wed Aug 23 04:43:05 2017. Dependencies resolved.
Problem: cannot install the best update candidate for package firefox-55.0.1-1.fc26.x86_64
- nothing provides nspr >= 4.16.0 needed by firefox-55.0.2-1.fc26.x86_64
nspr is still in updates-testing. If you want you can run "dnf --enablerepo updates-testing update firefox"
Thank you! I have just done that. Because dnf wasn't able to update Firefox to the best version it removed it instead! I assume this is a result of the combination --best --allowerasing which I generally use. I've never had it just remove things completely leaving no version installed though :(
That doesn't look right. AFAIK "--allowerasing" will delete a package that is blocking something else from updating, but not otherwise. It shouldn't remove a package just because it can't get the latest version.
poc
On 24/08/17 10:59, Patrick O'Callaghan wrote:
On Thu, 2017-08-24 at 09:03 +0100, Christopher Ross wrote:
On 23/08/17 14:27, Ed Greshko wrote:
On 08/23/2017 08:40 PM, Bob Goodwin wrote:
# dnf upgrade Last metadata expiration check: 0:00:00 ago on Wed Aug 23 04:43:05 2017. Dependencies resolved.
Problem: cannot install the best update candidate for package firefox-55.0.1-1.fc26.x86_64 - nothing provides nspr >= 4.16.0 needed by firefox-55.0.2-1.fc26.x86_64
nspr is still in updates-testing. If you want you can run "dnf --enablerepo updates-testing update firefox"
Thank you! I have just done that. Because dnf wasn't able to update Firefox to the best version it removed it instead! I assume this is a result of the combination --best --allowerasing which I generally use. I've never had it just remove things completely leaving no version installed though :(
That doesn't look right. AFAIK "--allowerasing" will delete a package that is blocking something else from updating, but not otherwise. It shouldn't remove a package just because it can't get the latest version.
Well that is exactly what happened. The command
dnf --refresh --best --allowerasing upgrade
Could not update Firefox because of the missing dependency (nspr) so it removed Firefox completely instead. This is not what I expected to happen. This is the command I generally use to update the system, pretty much daily.
Subsequently entering the command
dnf install firefox
installed firefox.x86_64 54.0-2.fc26, not the 55.0-1 that it removed.
I then followed Ed Greshko's advice (above) to enable the updates-testing repository to get the required dependency and that worked, so that I now have firefox.x86_64 55.0.2-1.fc26 installed.
Regards, Chris R.
On Thu, 2017-08-24 at 12:30 +0100, Christopher Ross wrote:
On 24/08/17 10:59, Patrick O'Callaghan wrote:
On Thu, 2017-08-24 at 09:03 +0100, Christopher Ross wrote:
On 23/08/17 14:27, Ed Greshko wrote:
On 08/23/2017 08:40 PM, Bob Goodwin wrote:
# dnf upgrade Last metadata expiration check: 0:00:00 ago on Wed Aug 23 04:43:05 2017. Dependencies resolved.
Problem: cannot install the best update candidate for package firefox-55.0.1-1.fc26.x86_64 - nothing provides nspr >= 4.16.0 needed by firefox-55.0.2-1.fc26.x86_64
nspr is still in updates-testing. If you want you can run "dnf --enablerepo updates-testing update firefox"
Thank you! I have just done that. Because dnf wasn't able to update Firefox to the best version it removed it instead! I assume this is a result of the combination --best --allowerasing which I generally use. I've never had it just remove things completely leaving no version installed though :(
That doesn't look right. AFAIK "--allowerasing" will delete a package that is blocking something else from updating, but not otherwise. It shouldn't remove a package just because it can't get the latest version.
Well that is exactly what happened. The command
dnf --refresh --best --allowerasing upgrade
Could not update Firefox because of the missing dependency (nspr) so it removed Firefox completely instead. This is not what I expected to happen. This is the command I generally use to update the system, pretty much daily.
The man page for dnf says: "Allow erasing of installed packages to resolve dependencies" (which is actually not as clear as it might be - would removing every package on the system resolve dependencies?).
However that is consistent with what it did in your case. It removed FF because it couldn't update nspr, not "Because dnf wasn't able to update Firefox to the best version it removed it instead", which is the phrase I was reacting to.
poc
On 24/08/17 13:48, Patrick O'Callaghan wrote:
The man page for dnf says: "Allow erasing of installed packages to resolve dependencies" (which is actually not as clear as it might be - would removing every package on the system resolve dependencies?).
However that is consistent with what it did in your case. It removed FF because it couldn't update nspr, not "Because dnf wasn't able to update Firefox to the best version it removed it instead", which is the phrase I was reacting to.
I disagree. It could not install the updated Firefox because it depends on a version of nspr that has not been released yet. Removing the currently installed Firefox did not resolve any dependencies at all. At best, that would imply that it needed to uninstall Firefox because it was blocking the update of something else, which so far as I can tell is not the case.
Or, if that is the case, which packages in the current update DO depend on the newest version of Firefox, which in turn depends on a package that hasn't been released yet? Surely under your interpretation they would have been removed too?
Regards, Chris R.
On Thu, 2017-08-24 at 13:59 +0100, Christopher Ross wrote:
On 24/08/17 13:48, Patrick O'Callaghan wrote:
The man page for dnf says: "Allow erasing of installed packages to resolve dependencies" (which is actually not as clear as it might be - would removing every package on the system resolve dependencies?).
However that is consistent with what it did in your case. It removed FF because it couldn't update nspr, not "Because dnf wasn't able to update Firefox to the best version it removed it instead", which is the phrase I was reacting to.
I disagree. It could not install the updated Firefox because it depends on a version of nspr that has not been released yet. Removing the currently installed Firefox did not resolve any dependencies at all. At best, that would imply that it needed to uninstall Firefox because it was blocking the update of something else, which so far as I can tell is not the case.
Or, if that is the case, which packages in the current update DO depend on the newest version of Firefox, which in turn depends on a package that hasn't been released yet? Surely under your interpretation they would have been removed too?
I think the exact meaning of the man-page phrase is unclear, so I for one can't tell if what happened is a bug or a feature. Either way, I'd suggest you file it as a bug against dnf and maybe someone will react.
poc
On 08/23/2017 05:40 AM, Bob Goodwin wrote:
Can I determine if "drpms" are being provided before actually downloading them? If so how?
You can load: http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$base...
...in your browser. Though it's still possible that dnf will get a mirror that's out of sync, and won't have the contents you see.
Gordon Messmer wrote:
I don't see a "drpms" directory in the fedora 26 "updates" directory. It's still present for f25 and f27. I haven't seen any notices about that, so it might be a failure. I'm asking in the #fedora IRC channel. I'll file a bug later if needed.
Did you get any response?
I've just updated two F26 machines and not a single DRPM was used.
Ron
On 08/25/17 04:02, Ron Yorston wrote:
I've just updated two F26 machines and not a single DRPM was used.
Ron _______________________________________________
. I saw the same result this morning, two "dnf upgrades" without one delta rpm. It looks as though they've abandoned it?
Bob
On 08/25/2017 05:17 PM, Bob Goodwin wrote:
On 08/25/17 04:02, Ron Yorston wrote:
I've just updated two F26 machines and not a single DRPM was used.
Ron _______________________________________________
. I saw the same result this morning, two "dnf upgrades" without one delta rpm. It looks as though they've abandoned it?
FWIW, I had an F25 VM that had not been updated in a while. When I updated it there were quite a few *.drpm files downloaded.
On 08/25/17 05:26, Ed Greshko wrote:
this morning, two "dnf upgrades" without one delta rpm. It looks as though they've abandoned it?
FWIW, I had an F25 VM that had not been updated in a while. When I updated it there were quite a few *.drpm files downloaded.
-- Fedora Users List - The place to go to speculate endlessly
. There were some ,drpms not long ago but recently, I don't know exactly when it began, there have been none. So I am not surprised at the result you saw today.
Tor a long time, with other Fedora versions, it seemed unusual to see a plain .rpm, at least that is my impression.
Something has changed. O can live with it simply by doing my updates early in the day when my usage is not limited.
On 25/08/17 12:30, Bob Goodwin wrote:
On 08/25/17 05:26, Ed Greshko wrote:
this morning, two "dnf upgrades" without one delta rpm. It looks as though they've abandoned it?
FWIW, I had an F25 VM that had not been updated in a while. When I updated it there were quite a few *.drpm files downloaded.
-- Fedora Users List - The place to go to speculate endlessly
. There were some ,drpms not long ago but recently, I don't know exactly when it began, there have been none. So I am not surprised at the result you saw today.
Tor a long time, with other Fedora versions, it seemed unusual to see a plain .rpm, at least that is my impression.
Something has changed. O can live with it simply by doing my updates early in the day when my usage is not limited.
I looked at the UK mirror. fc25 has a drpms folder; fc26 does not.
https://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/up...
... but it's on the Irish site, so it might be a local mirroring decision?
https://ftp.heanet.ie/mirrors/fedora/fedora/linux/updates/26/x86_64/drpms/
John P
On 08/25/2017 03:27 AM, Ron Yorston wrote:
I've subscribed to the infrastructure mailing list and have asked there.
Good idea. I don't think it's been abandoned. At least, I haven't seen any proposals to do so. The directory is present again on the mirrors I've seen. However, I don't see any new drpms inside that directory, so it looks like the build or push process isn't creating new deltas.
On 08/25/2017 09:05 AM, Gordon Messmer wrote:
On 08/25/2017 03:27 AM, Ron Yorston wrote:
I've subscribed to the infrastructure mailing list and have asked there.
My reply there for folks here:
Short answer: Yes. We know they are currently not working for f26.
Long answer: With the addition of alternative arches in f26, we cannot do drpms the same way as we used to, because some of the packages are under fedora-secondary and some are under fedora. We need a fix for https://github.com/fedora-infra/bodhi/issues/1685 in order to get this working again.
Hopefully we will have a patch soon and they will be re-enabled.
Good idea. I don't think it's been abandoned. At least, I haven't seen any proposals to do so. The directory is present again on the mirrors I've seen. However, I don't see any new drpms inside that directory, so it looks like the build or push process isn't creating new deltas.
I was hoping we could fix this quickly, but it needs some coding and it's just not been gotten to yet. ;(
Sorry for the trouble.
kevin
On 08/25/17 14:53, Kevin Fenzi wrote:
We know they are currently not working for f26.
Long answer: With the addition of alternative arches in f26, we cannot do drpms the same way as we used to, because some of the packages are under fedora-secondary and some are under fedora. We need a fix for https://github.com/fedora-infra/bodhi/issues/1685 in order to get this working again.
Hopefully we will have a patch soon and they will be re-enabled.
+
Delta RPMs appear to be working once again this morning:
Total 436 kB/s | 22 MB 00:52 Delta RPMs reduced 73.0 MB of updates to 22.4 MB (69.1% saved)
Bob
On Sun, Sep 03, 2017 at 03:50:45AM -0400, Bob Goodwin wrote:
Hopefully we will have a patch soon and they will be re-enabled.
Delta RPMs appear to be working once again this morning:
Yes -- some people hacked on this during Flock and fixed the problems.
On 09/03/2017 12:50 AM, Bob Goodwin wrote:
On 08/25/17 14:53, Kevin Fenzi wrote:
We know they are currently not working for f26.
Long answer: With the addition of alternative arches in f26, we cannot do drpms the same way as we used to, because some of the packages are under fedora-secondary and some are under fedora. We need a fix for https://github.com/fedora-infra/bodhi/issues/1685%C2%A0 in order to get this working again.
Hopefully we will have a patch soon and they will be re-enabled.
Delta RPMs appear to be working once again this morning:
Total 436 kB/s | 22 MB 00:52 Delta RPMs reduced 73.0 MB of updates to 22.4 MB (69.1% saved)
I meant to send an email on this, but have been traveling...
yes, F26 drpms should be all fixed up now. :)
kevin