Skip to main content
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: `ckb-next` mismatch (Read 573 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

`ckb-next` mismatch

here the output of:
Code: [Select]
paru ckb-next
5 aur/ckb-next-git 1:0.5.0.r0.g519330ed-1 [+15 ~1.08]
    Corsair Keyboard and Mouse Input Driver, git master branch
4 universe/ckb-next-s6 20210928-1 [3.63KiB 517B]
    s6 init script for ckb-next
3 universe/ckb-next-runit 20220716-1 [9.05KiB 172B]
    Runit service script for ckb-next
2 aur/ckb-next 0.5.0-2 [+47 ~1.68] [Installed]
    Corsair Keyboard and Mouse Input Driver, release version
1 universe/ckb-next 0.4.4-4 [1.11MiB 2.82MiB] [Installed: 0.5.0-2]
    Corsair Keyboard and Mouse Input Driver, release version
ones was also an `ckb-next-openrc`.

I Installed the newer AUR-Version that's also the only working version.
The problem is, if I (for backup &| restore) use:
Code: [Select]
pacman -Qqm
wrongly, `ckb-next` is not listed because appear that a `universe` old-version of the app is installed, hence... my backup-list is wrong and consequently a restore not possible or incomplete.

I don't think the older version (0.4.4-4) will work under other init-systems, for this to works you/we need the AUR-Version (0.5.0-2).

So, thanks for have deleting `ckb-next-openrc` but, there (as you can see) is still a problem.

I'm sorry for disturbing you again with this topic, but, either you use the AUR-version in each init-system (universe repo) or you delete all ckb-next.

I think you/we need to address ckb-next to fake-systemd by compiling/installing, what do you think about?
Do we have a chance to get it right? Or is a workaround there?

Thanks in advance for your explanation and work.

Re: `ckb-next` mismatch

Reply #1
I'm not entirely sure what you are asking in the second part of your post but to address the first part the -m option to pacman -Q lists foreign packages. Anything installed from repos listed in pacman.conf is not considered a foreign package.

To list explicitly installed packages
Code: [Select]
pacman -Qqe
To list explicitly installed repo packages
Code: [Select]
pacman -Qqen
To list explicitly installed foreign (AUR etc) packages.
Code: [Select]
pacman -Qqem

As to the second part it seems ckb-next does have support for a few inits but the version provided on the AUR provides for systemd (as you'd expect).

Which init do you use?
https://github.com/ckb-next/ckb-next/tree/master/linux gives as clue as to which are supported and you'd need to change line 33
Quote
-DFORCE_INIT_SYSTEM="systemd"
to the one you require and build the package locally. At least that's my guess.

Or wait until the one in universe is updated.

Or just install the AUR one and copy the relevant service file(s) from the github page and put them in place manually.





Re: `ckb-next` mismatch

Reply #2
I'm not entirely sure what you are asking in the second part of your post but to address the first part the -m option to pacman -Q lists foreign packages. Anything installed from repos listed in pacman.conf is not considered a foreign package.
Thanks first for your answer, now is something clearer (or maybe not), in fact here the two outputs:
Code: [Select]
pacman -Qqm
autoupgrade
brother-hl3152cdw
ceph-libs
cmst
downgrade
gconf
ipw2100-fw
ipw2200-fw
paru
timeshift-autosnap
yandex-browser-beta
and...
Code: [Select]
pacman -Qqem
autoupgrade
brother-hl3152cdw
cmst
downgrade
ipw2100-fw
ipw2200-fw
paru
yandex-browser-beta
if your commands are right, apparently, `ceph-libs`, `ckb-next`, `gconf` & `timeshift-autosnap` are NOT AUR-Packages, but, searching with paru are the results different:
Code: [Select]
1 aur/ceph-libs 17.2.5-1 [+3 ~1.70] [Installed: 15.2.14-6]
    Distributed, fault-tolerant storage platform delivering object, block, and file system

2 aur/ckb-next 0.5.0-2 [+47 ~1.68] [Installed]
    Corsair Keyboard and Mouse Input Driver, release version
1 universe/ckb-next 0.4.4-4 [1.11MiB 2.82MiB] [Installed: 0.5.0-2]
    Corsair Keyboard and Mouse Input Driver, release version

1 aur/gconf 3.2.6+11+g07808097-10 [+109 ~6.31] [Installed]
    An obsolete configuration database system

1 aur/timeshift-autosnap 0.9-1 [+44 ~3.08] [Installed]
    Timeshift auto-snapshot script which runs before package upgrade using Pacman hook.

I install intentionally: `brother-hl3152cdw`, `ckb-next`, `cmst`, `downgrade`, `paru`, `timeshift-autosnap` & `yandex-browser-beta`... hence, something can't be correct.

I use `openrc` and this is well supported (thanks for your Link) and works also perfect without any mofication.

The topic is: I cannot let issue a file containing only AUR packages I can install with `paru -S --needed --noconfirm <packages-names>` because paru could pick ckb-next from repository with ver. 4 and not 5 like pacman done as `chb-next-openrc` was in the repository.

The problem is: The package-developers make a good job that don't require any manual adjustment from user (apart to add and start it in openrc), but... still required some "attentions" to avoid install the wrong package.

The general recommendation is: "If you can, don't use AUR-Packages" and now!? I have an AUR-Package installed with an AUR-Helper and the System "pacman" claim to be a repo-package. The user respecting those guidelines install ckb-next with pacman and this version don't work.

Sorry, I cannot explain more simple than I have just done.


Re: `ckb-next` mismatch

Reply #3
Well my general recommendation is (and i speak only for myself)

  • Use Artix repo packages where available
  • Use Arch repo packages where Artix repo packages don't exist
  • Use the AUR otherwise but DO read the PKGBUILD to see what's being done
  • Where something I want isn't in the above. package it myself unless it's a one file deal in which case it goes in either /usr/local/bin or ~/bin
  • Accept the 'universe' repo is a bit of an oddity with mainly AUR packages prebuilt for convenience but updates can be slow

With number three I admit that after the initial review I tend not to review again. Ideally I should.
With number five most of the time if you have a powerful enough machine you can just build the AUR version if you need the up to date package (As you have done). Sometimes though slight changes may have been made to the PKGBUILD to accommodate for the lack of systemd. If you run into problems you can nearly always find the Artix PKGBUILD here https://gitea.artixlinux.org/ and compare with the one from the AUR

AUR helpers can generally install dependencies also from the AUR. Those dependencies won't show with pacman -Qqem because they weren't explicitly installed. That probably accounts for the difference?

The end bit of what you're saying I don't totally follow.
If you have ckb-next installed and working I'd be happy with that.

As far as the AUR goes it makes sense for an arch based distro to state "We only support the packages in our own repos not the AUR and not the Arch repos". But in my case I need packages from all of them. So I use all of them.

Using arch in general requires a bit more attention to what's going on with your system than with many distro's.
Using an arch based distro stripped of systemd and with a choice of inits to choose from requires an extra bit of attention on top of the above.

Praise be the Artix devs that make all this possible  :D

Edit: I missed out the Arch repo's

Re: `ckb-next` mismatch

Reply #4
Just FYI, I did remove ckb-next just now because it is indeed dated (and unmaintained) and it does get annoying when it blocks the AUR versions. The couple of init scripts are entirely optional and as far as I can tell from glancing at the actual git repo, there's no systemd dependency or anything. It's just a typical daemon you run like any other.

 

Re: `ckb-next` mismatch

Reply #5
Just FYI, I did remove ckb-next just now because it is indeed dated (and unmaintained) and it does get annoying when it blocks the AUR versions. The couple of init scripts are entirely optional and as far as I can tell from glancing at the actual git repo, there's no systemd dependency or anything. It's just a typical daemon you run like any other.
Thanks  for you rapid help and action.

After a `pacman -Syy`, both `pacman -Qqm` and `pacman -Qqem` and `paru ckb-next` shows the correct answer regarding `ckb-next`.

FYI, Octopi show also `ckb-next-runit` ver. '20220716-1' and `ckb-next-s6` ver. '20210928-1' but I don't know how reliable are the info of this app.

For me, is the topic solved. Thanks again for your support I appreciate every time.