[SOLVED] pacman package-query: requires pacman<3.6

[moonman]

I ran into the problem today. People at archlinux forums had the same problem, here's how to resolve it:

Purge all the packages that require pacman < 3.6 (remember them, if they are not pacman related(i had to remove devtools))
$this->bbcode_second_pass_code('', 'pacman -Rdd pacman-color
pacman -Rdd package-query
.
.
.')

Then do the upgrade
$this->bbcode_second_pass_code('', 'pacman -Suy')

Then reinstall the packages.

Cheers

[skealoha86]

Is there an easy way to get a list of packages that aren't compatible?

[moonman]

When you do pacman -Suy it tells you.
Most of the time it's just one package which is in the title of this thread

[WarheadsSE]

I cheated.

pacman -Syu

Do you want to do this first? [Y] N

pacman-keys --init

*generate a lot of entropy*

done.

[moonman]

$this->bbcode_second_pass_quote('WarheadsSE', 'I') cheated.

pacman -Syu

Do you want to do this first? [Y] N

pacman-keys --init

*generate a lot of entropy*

done.

[slycat]

It seems the pacman issues resolved themselves. I had the issue in the title earlier today, but alas I try again about six hours later and everything worked fine. I believe WHSE caught it after things were ironed out, because I ended up doing the same exact thing

[kmihelich]

I just got those packages upgraded. The stuff we publish from AUR doesn't hit any radar until the community says something usually.

[slycat]

I didn't bring it to the attention of you guys figuring that it was an issue from Arch-side (I did not have time to read into the cause of the problem). I figured not bother you devs with something that was Arch's fault anyway, but from now on I'll have the IRC hotkeyed to my keyboard at the first sign of an issue

[kmihelich]

There are important things that need to be distinguished. We build the main repos (core, extra, and community) from packages tracked upstream. If Arch dumps something from what they track, we dump it. If they add something, we add it. This happens automatically, and builds of these packages are queued in correct dependency order. There's more to it than this of course, but that's the main idea you need to understand. Some PKGBUILDs are designed too-x86 sometimes, or require specific ARM patches, and those end up in github. What's there in core/extra/community replaces what comes from upstream, but when Arch upgrades one of those packages we get notified through the build system that we need to upgrade ours.

AUR is an entirely separate thing from this mechanism. We don't have any automatic package version checking in place against AUR packages, and the only reason they're there is because of high demand from the community and because we understand that building packages on ARM without the kind of setup we use for cross-compiling, among other things, can just suck. However, it does take time to go through and check these packages for version bumps, time that doesn't become available often (we don't get paid for this, remember). So for AUR, I rely a lot on the community here to let me know that something has gone out of date or needs a rebuild.

What also needs distinguishing is what ends up being our problem, and what is something that propagates from upstream. If something is Arch's fault, which is pretty rare, chances are someone up there is working the issue and you probably won't even run into it. An example of this would be a bad PKGBUILD that got released into ABS that didn't build for them, and thus won't build for us, and you probably would never see any kind of negative outcome. This forum is also the place to post about problems, not Arch's mailing lists or bug tracker. Though if you actually want to get my attention you'll file an issue on github, but in that case it has to be a real issue, not user error.

[slycat]

Duly noted. From the tone of previous responses to issues found on the forums I figured it was best to refrain from creating a new topic to an issue that could easily be solved by searching archlinux directly or other places. I assumed there was a simple solution to the thread-title problem (such as a work-around that did not require the dev team's attention) but at the time was unable to begin finding a solution, so I never brought it up.

As a regular on these forums, I do understand that everyone on the dev team here are solely volunteering to keep up this work by parting off free-time, and I do not take it for granted. I'd like to help any way I can, including the option to hold-off on creating topics until I feel I've done all I can do on my own(may be a bad habit, I guess) and helping those with user-related issues before the dev team has to come in on it.

I did not mean to say things just *magically* cured themselves, I just assumed it was an Arch-related issue and not an ARM one. I thank you for fixing this (among plenty of other things behind the scenes) so that we can continue using ALARM without a hitch.