5-6X seems abnormal, even if the rochester servers get sluggish on weekends sometimes.
I think it's as simple as a system reboot then trying again.
If you are simply doing this: sudo eopkg it brave you should try again.
Unless CORE knows something about this Brave package, or mirror, that I don't. which is also a possibility.

Also, isn't Firefox installed by default?

    brent They're updating brave & firefox, not installing from scratch.

    lepanto eopkg (Solus' package manager) isn't too good at handling network interruptions so will timeout and fail sometimes. I just tried that particular file and it downloaded fine, I'd try again.

          still no luck 🙁
          brent

          The following package(s) are already installed and are not going to be installed again:
          brave
          No packages to install.

          ff n brave are installed but the problems are about upgrading...
          i think its about what Justin said about the Solus' package manager...it needs improvement....

              lepanto Try deleting your cache first then upgrade, sudo eopkg dc && sudo eopkg up

                  Justin
                  still...🙁
                  im wondering if there's a manual way to upgrade (e.g. download packages n install/upgrade somehow)

                      lepanto Eh, eopkg on its own is fine. It's the file downloading library that it uses that is getting worse over time.

                          6 months later

                          DataDrake

                          Hi DD..
                          Well, this isn't a bump - just confirmation that for me the update timeout error is Very Common.
                          I don't have a fast connection, but I'd like to believe it's reliable.
                          That would be australian ADSL2+ at the magnificent speed of between 3.6 and 5.8 KB/sec - depending on the weather and the state of the ancient cable we have.
                          The past few months have been pretty slow, so I simply ignored the (frequent) errors, but we've have a decent tech get in and repair the problems (there were many) with the line and now get almost 6MB/sec. Let there be unbounded joy - BUT, the timeout problem is still there.
                          I'm thinking that other than trying to have Tel$tra - the carrier - cache the repositories - What to do?

                          Please be aware that the carrier idea is mostly a joke - it's reticent to provide even basic services. That's by tradition, design and by definition.

                              So it doesn't look like the pisi patch I'm doing is doing retries on all the places I'd want, primarily on the bytes read error. It does for more (IOError, OSError, various content length issues) but the way it is setting the read timeout is effectively that it sets pycurl options for LOW_SPEED_LIMIT and LOW_SPEED_TIME. But here's the thing, curl is super dumb and actually returns a CURL_EOK (treating everything like it was fine) if it hits a speed limit, see: https://curl.haxx.se/libcurl/c/CURLOPT_LOW_SPEED_LIMIT.html

                              Since it returns an OK, it can't be handled (seemingly) by urlgrabber (the python library eopkg uses) or with the underlying pycurl curl object. Which means we can't handle it in eopkg / pisi.

                              So it should handle the unsatisfiable error (416) and the like, but not the read timeout. Sorry, I tried but unfortunately this codebase is well...we really need sol (our planned rewrite) and I'll leave it at that >.<

                              8 months later

                              Delaying the update for a few hours, the problem was solved. (Solus 4.2 Plasma, first update. In order to avoid corrupting the whole system in case of serious error I do it in console, Ctrl+Alt+F2. That same error involved Firefox, then breeze theme, then Libreoffice, about 5 or 6 times, as the update was each time resumed from zero.)