Update of libpsl from "system-testing" could not occur as libidn2 was missing had to install this from AUR but first had to import packager's signature.
If you use Artix testing repos, you should also use Arch testing repo, libidn2 is there and soon will be in ours.
You say should but this is the first time I encounter this rule. Are we expected to smell our nails short of speak?
warning: cannot resolve "libidn2", a dependency of "libpsl"
:: The following package cannot be upgraded due to unresolvable dependencies:
libpsl
Would this be the modification (for now)?
[extra-testing]
Include = /etc/pacman.d/mirrorlist-arch
[extra]
Include = /etc/pacman.d/mirrorlist-arch
[community-testing]
Include = /etc/pacman.d/mirrorlist-arch
[community]
Include = /etc/pacman.d/mirrorlist-arch
I hope you don't mean [core] and core-testing!
Extra-testing doesn't seem to exist, so scrap that try.
community-testing results in the same deficit for libpsl
So what else is there to try? Core and core-testing?
Let's see!
Nope, core-testing does not exist either, but with just core the result is the same.
error: failed to prepare transaction (could not satisfy dependencies)
:: libpsl: requires libidn2
Should this be revised and mean experienced ARCH users?
Because experience in other linux results in smelling your fingers while in Artix.
And if it is so, and I would have been told that it takes experience in Arch to move to Artix I wouldn't be here complaining about this, because I dislike Arch.
Which also means that @Artoo has been lying in his statements from day 1 about the smooth move from Manjaro to Artix just so he doesn't burn any professional bridges and let them be off the hook (as an unofficially declared systemd-ONLY distribution).
So what do you mean by arch-testing?
Wait a damn minute, there is "indirect implication" that there exists, in unlike artix-philosophy of repository naming, a [testing]
repository. So let us try this pacman -Sy AGAIN for the n-th time. (reference: https://wiki.archlinux.org/index.php/DeveloperWiki:Community_move_to_devtools about the only one I found in wiki and manuals in Arch)
Woooo...hoo..... tons of things to upgrade to, and break your poor artix.
So I will refrain and just install the missing dependency
$ pacman -S libidn2
Then go back for the n+1-th time and erase all the Arch Crap, or wait another damn minute, maybe I should leave community-testing alone, after all we are testing in murky waters, might as well be the straw that broke the camels back.
Then for the n+2-th time run
$ pacman -Syu and see if libpsl installs OK.
Aaaaahhhh Success!
Another half day lost in Artix "mysticism".
And that is how this fucking cookie crumbles!
Not for the inexperienced Arch user for sure.
Not for Manjaro users either, don't listen what they will try to sell you. Nothing like Manjaro!
You have to learn how to ride here all over again with the handlebars behind your back looking at the rear mudflap's "mirror"-list!
Go ahead, tell me I am being unreasonable and shut this thread down as well, mr moderator.
And now you can mark it SOLVED without any mysticism about the solution!
I had the same issue....also my first time encountering anything like this. I simply downloaded libidn2 from Arch testing and manually installed it, then was able to update libpsl. Perhaps not an ideal solution, but no biggie. Running testing repos does have it's caveats, no? ;)
Best regards.
@ Nous said Arch testing repo, libidn2 is there and soon will be in ours ........ which is great but don't mark this as solved until the later happens.
Note it was not me who marked it as solved!
The same pkg (version) exists in AUR, I can't be sure whether it has ARCH modifications in testing, but wouldn't that be indicated in the version #? I have a feeling that it does not always happen.
It actually took quite a while to find out through literature how to activate arch-testing.
In devuan I have canibalized pkgs from about 5 other distributions based on debian with unexpected success. In arch I am half blind. You see, in Manjaro it was easy, one repository many mirrors, and then there were testing and unstable. The user had no clue how a pkg went from arch to manjaro.
In devuan they have what they call merged and devuan only repositories. Merged is devuan specific pkgs and the rest of debian's repository. But this has turned into a static distribution instead of rolling so one begins to wonder, "a merged debian repository which is how many months old?"
Same goal different paths.
Well intuitively I would suspect testing to occasionally conflict with system-testing since Arch testing has core packages in there that might get updated first and something bad might happen if you're not paying attention (perhaps I'm wrong on this though; someone can correct me). However, you definitely should enable Arch testing since I just made the mistake of updating without testing enabled. The new update of icu in system-testing appears to have broken texlive-bin (which recently updated in Arch's testing repo but not the extra one) for me and now I'm getting a "libicuuc.so.59: cannot open shared object file" error while trying to use pacman. No biggie, I'll just do a live boot to fix it. So anyone out there that is rolling Artix testing repos, but not Arch's should really go full on testing or go back to all stable. I suppose I'll go all out and do full bleeding edge then.
There was a ton of stuff that seem upgradeable with arch-testing.
I suspect it is a matter of hours for newly missing dependencies to be edited and moved to artix-testing, so patience is of essence. I actually think the devs maybe should slow down rather than trying to catch up.
Unless you have cleaned up your cache you should have a copy of the previous version of the pkg to revert to.
Maybe place it in the ignore list in pacman.conf for a couple of days so it does not affect the remaining updates.
It's a bit of a catch-22 though. Since this is Arch, people are probably going to want bleeding-edge. I know one of the reasons why I switched to the testing repos was because I don't want to fall so far behind Arch. The regular stable repos do seem relatively slow to me but they definitely will be quite a bit behind Arch. It's just the nature of the thing.
Now someone must be playing games on us on Arch.
I tried getting libidn2 through [testing] and it is not there anymore.
It was there about 10hrs ago.
There were also I think two versions of it in AUR, libidn2 and libidn2-git, same version number as the one missing.
Now there is only -git. Have I gotten a roque file that was droppoed from all mirrors?
Were things like this happening in Arch frequently?
There was one recent incidence in Debian with qupzilla in Sid. It was left behind by more than 2 years. Suddenly it
appears in sid (unstable debian) but its dependencies (qtwebkit5 ?? I think it was) were missing dependencies. It was left like this for months.
Suddenly all its dependencies were met only it wanted to bring systemd in and its gangster buddies, while wiping half of the core system of the installation.
I'm not 100% sure on this, but I believe packages in Arch move in and out of testing. The new version of libidn2 is in core now.
I thought arch core should not be enabled as it contains packages with systemd dependencies so the fact it is in core is not much help to artix users?
Well Arch testing has a bunch of packages that eventually go into core too, so you'll have the same dilemma really. You can temporarily enable core just to grab that one package and then disable it again.
@nous said "If you use Artix testing repos, you should also use Arch testing repo" which to be honest I don't really like. I wish in cases like this assuming we need libpsl and it now has a dependency of libidn2 then it would be nice if this could be added to one of our repo's in a timely manner. There does not appear to be too many of them so perhaps not a very big job?
Well whatever you do, don't update Artix testing without updating libidn2 and libpsl. You'll have a bad time since pacman will search for version of libicuuc.so.59 (the old version) instead of libicuuc.so.60. I just did some more testing and that was what caused my library error earlier. Hopefully that libidn2 package will find its way into system-testing soon.
Robin I think you took it out of context, and with one liner instructions I do not blame you.
As dudemg says, running testing is just as risky as core, as everything ending up in core has gone through testing.
A new package being in testing in the morning and in stable in the evening is what Arch calls cutting edge. Ok debian is slow and conservative but I call this hemorrhaging edge. Who did the testing? Did I do it 15hrs away while you are in stable and never saw it coming?
What I think
@nous implied was that at times you may have to activate arch core and testing to snatch something artix hasn't had time to hack and return to artix. Meaning you comment out core and testing and reupdate.
You upgrade ONCE with core, maybe testing too if you are not very lucky, and I can warranty you will be broken. And this is getting worse and worse with systemd. Now much of QT stuff pull systemd dependencies, before we know it you will need systemd to run vi or nano.
We use our testing repos to, well, test the packages for functionality and breakage. We can't possibly remember by heart every single dependence of a package nor which repo they're in. When libpsl in [system-testing] revealed its new libidn2 dependency, we put it in our updated package import list and is scheduled for build.
What I meant to say with my first post is that using testing repos isn't for the faint of heart. People should be both able to resolve problems
and kindly report them to the forum, or even better on our github repositories (https://github.com/artix-linux).
Actually, this should be front page material: it's better to open issues on Github because the devs can see them more easily and act on them; a post in the forum can be easily overlooked.