@bobcollins42 You could also try to put the [antergos] section in /etc/pacman.conf below the Arch repo entries; either below [multilib] or even below the comment block at the bottom of the file. Don’t forget to run a “sudo pacman -Syyu” to update the database just to be sure.
If I’m not mistaken (running vanilla Arch here) this should make the Arch repo take precedence over the antergos repo, therefore making “quazip” from the Arch repo the “preferred” one. In worst case you have to force a reinstall of the package to switch from the “antergos” one to the “Arch” one.
The reason for the problem seems to be that Arch’s KeePassXC package depends on “quazip” (which goes totally unexplained as that Qt/C++ wrapper isn’t a dependency of the official source, at least I can’t seem to find it mentioned anywhere on the KeePassXC GitHub page) and that Antergos has its own “quazip” version in the “antergos” repo that overrides Arch’s package.
While things are up in the air (the infrastructure behind Antergos slowly winding down) I think you are left with only two choices …
Either use the official “AppImage” packaged version (keepassxc.org -> Download) under your user account or enable the AUR and install the “keepassxc-git” version (compiles from source, which comes with the latent danger of the compile bombing out apart from it taking a bit to compile (depending on the speed of your processor)).
Things should normalize once the Antergos devs transistioned the install base over to Arch, which they, IMO, should do rather sooner than later.
anthology/ (ænˈθɒlədʒɪ) /
noun plural -gies
a collection of literary passages or works, esp poems, by various authors
any printed collection of literary pieces, songs, works of art, etc
See the bolded part. If anything, Antergos was a work of art if we put the one or another niggle with Cnchi aside, and given that spirit is being carried on the name would be a subtle hint of that idea.
Unless Antergos developers packed whatever is causing the issue, they are not responsible to whatever error you’re facing.
Well thanks for pointing out this “no liability” declaration, that’s the most ridiculous excuse for lacking Q/C (be it Arch or Antergos) I’ve ever read.
Never mind, come tomorrow morning I’ll research Manjaro or Solus as a replacement because I’ve got work to do and ain’t got time to fix breakage for which no one is responsible.
You have my permission to delete my account, our business is concluded.
Just spotted on the Arch Forums…
Well, at least we now also know that it affects Firefox as well - and the guy who made that post also narrowed down the packages.
Though… chromium-widevine can be scratched off the list as our “Antergos” version (1:4.10.1146.0-2) doesn’t seem to give any problem.
Guys, something went completely wrong with the latest set of system updates…
When I try to sign into my Google account Chromium dies with a “Aw Snap” and keeps on "Snap"ing till the browser is restarted.
Downgrading just Chromium alone doesn’t solve the problem because of some deeper dependencies within the “icu” stuff.
No matter what I try … I can’t sign in to Google in without Chromium losing its marbles.
For the time being I got s**t back to work by downgrading the latest set of updates, which were …
webkit2gtk (2.20.3-1 -> 2.20.3-2) qt5-webkit (5.212.0alpha2-18 -> 5.212.0alpha2-19) qt5-webengine (5.11.1-2 -> 5.11.1-3) qt5-location (5.11.1-1 -> 5.11.1-2) qt4 (4.8.7-24 -> 4.8.7-25) poppler-qt5 (0.64.0-1 -> 0.67.0-1) qt5-base (5.11.1-1 -> 5.11.1-2) poppler-glib (0.64.0-1 -> 0.67.0-1) libreoffice-fresh (6.0.6-1 -> 6.0.6-2) raptor (2.0.15-8 -> 2.0.15-9) libzmf (0.0.2-3 -> 0.0.2-4) libvisio (0.1.6-3 -> 0.1.6-4) libqxp (0.0.1-2 -> 0.0.1-3) libqalculate (2.6.1-1 -> 2.6.1-2) libmspub (0.1.4-2 -> 0.1.4-3) libical (3.0.3-2 -> 3.0.3-3) libe-book (0.1.3-2 -> 0.1.3-3) libcdr (0.1.4-3 -> 0.1.4-4) harfbuzz-icu (1.8.5-1 -> 1.8.6-1) ghostscript (9.23-1 -> 9.23-2) cups-filters (1.20.4-1 -> 1.20.4-2) poppler (0.64.0-1 -> 0.67.0-1) chromium (68.0.3440.84-1 -> 68.0.3440.84-2) openjpeg2 (2.3.0-2 -> 2.3.0-3) harfbuzz (1.8.5-1 -> 1.8.6-1) libxml2 (2.9.8-3 -> 2.9.8-4) boost-libs (1.67.0-6 -> 1.67.0-7) icu (61.1-1 -> 62.1-1)
So… thanks for the great breakage… this was total fun to deal with when you need to get to your god-damn e-mail account.
@toxpal The Intel Core i5 8400 is fully supported since Linux Kernel 4.15
I don’t know if the LTS kernel (4.14.56-1 at the time of writing) contains the necessary backports to properly support processors which haven’t been around as the 4.14 series came out … it being a LTS kernel one would actually assume that the “hardware enablement” would be backported.
If you’re on the rolling kernel (4.17 series) you should certainly be good.
@phunk-n-further, I tried SoundConverter, fre:ac and some other (can’t remember the name).
I usually convert only one file at a time, but I believe multiple cores should be used for any number of files?
Well, if the GUIs you tested so far are just graphical front-ends to things like “lame” (MP3 encoder) or “flac” (FLAC de-/encoder) then all I can tell you is that you won’t see multi-threading going on simply because the very command-line utility the GUI is relying upon is single-threaded - and I’m referring to the versions out of Antergos’ repository.
If you know that, for example, lame should be able to run multi-threaded given it got compiled that way … well … the only option would be to resort to the Arch Wiki and compile the package(s) in question to include support for multi-threading.
Another way would be to cobble up a bash script and run several encoder instances in parallel, each encoding a file (by launching it, for example, via “parallel” - a very nifty command-line tool). They should actually spawn across cores and not get pinned to the very same core. This is what I’ve done (bash script) as I’m currently re-encoding all my audio CDs into FLAC.
As for your question about “multiple cores should be used for any number of files” … well … it depends on the type of workload on how you best approach multi-threading.
Doing stuff like encoding video, applying a filter to a image (GIMP), ray-tracing a scene (Blender) can only be chopped up into chunks… all of the cores are working on just a segment - making them work on several different files wouldn’t make sense.
As for encoding audio … multi-threading the encode may make sense, and net some performance gain, on very large pieces of audio (i.e. a podcast audio that is several hours long). For short pieces I think the performance is good enough … I mean, a twelve second encode time for a WAV that is almost seven minutes long isn’t that shabby. This was “lame” encoding the ripped WAV into a 320Kbps CBR MP3, it takes 8 seconds to turn it into a FLAC (on Threadripper 1950X). In short, I’m not sure if you would see any noticeable performance gains in this particular scenario (a rather short file).
However… try and give “ffmpeg” a try. It can not only encode/transcode video, it also supports audio. Since ffmpeg is multi-threaded it should actually spread the task across all available cores.
As for the “always pins to the same core” … see joekamprad’s advice above. There’s something not entirely right when you see an odd behavior like this we can’t reproduce.
@toxpal Entirely depends if the software in question is multi-threaded and / or has been compiled with multi-thread support.
Which program did use for your “audio conversion”? You didn’t drop a name.
As an example:
7-zip (create/extract) uses all cores
rar (I’m using the RarLabs version) also uses all cores (although not to 100%)
lame (wav --> mp3) only runs on one core
flac (wav --> flac) only runs on one core
So… yea… there are programs which run on only one core because they are either not multi-threaded or have not been compiled to support multi-thread.
That being said, stuff like ffmpeg or handbrake (video encode/transcode) do make use of multiple cores.
Though, it remains a matter of question if you would actually see any performance gain … “lame” takes 12 seconds to encode a 6:48 long track (Chris Rea - Road To Hell [Long Version]), and “flac” is even faster though it also runs on just one core.