Can't reproduce here. ut I'm on systemd and definitely have a different util-linux

Name            : util-linux
Version         : 2.33.1-2
Description     : Miscellaneous system utilities for Linux
Architecture    : x86_64
URL             : https://www.kernel.org/pub/linux/utils/util-linux/
Licenses        : GPL2
Groups          : base  base-devel
Provides        : rfkill
Depends On      : pam  shadow  coreutils  libsystemd  libcap-ng  libutil-linux
Optional Deps   : python: python bindings to libmount [installed]
                  words: default dictionary for look
Required By     : apr  arch-install-scripts  fakeroot  gupnp  jfsutils  mkinitcpio  ntfs-3g  rasqal  reiserfsprogs  ring-daemon  systemd  systemd-udev
Optional For    : None
Conflicts With  : rfkill
Replaces        : rfkill
Installed Size  : 11.64 MiB
Packager        : Bartłomiej Piotrowski <bpiotrowski@archlinux.org>
Build Date      : Thu 10 Jan 2019 11:06:42 AM AST
Install Date    : Mon 14 Jan 2019 10:04:07 PM AST
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

The thing that stands out right away though is that your fdisk is "local/" which means it is not the version from the repo. Maybe pacman -Su gptfdisk would fix you up?

and your perl is "local/" too..

please make sure both of these are the proper version from the repo.

"local" means that it is looking at your installation database as opposed to the sync repositories...

And pacman has no concept of where a package was installed from, only that it is installed. "local" always refers to the installation database, it's a reserved name and cannot be used to name a repository.

Now, it is clear parabola packages a second util-linux, see https://www.parabola.nu/packages/nonsystemd/x86_64/util-linux/

Downloading that tarball and running my linkages script (https://github.com/eli-schwartz/dotfiles/blob/master/bin/pkg-list-linked-libraries):

$ pkg-list-linked-libraries util-linux-2.32-3.nonsystemd1-x86_64.pkg.tar.xz libreadline
==> checking linked libraries for util-linux-2.32-3.nonsystemd1-x86_64.pkg.tar.xz ...
/usr/bin/chfn
  NEEDED               libreadline.so.7
/usr/bin/chsh
  NEEDED               libreadline.so.7
/usr/bin/fdisk
  NEEDED               libreadline.so.7
/usr/bin/sfdisk
  NEEDED               libreadline.so.7

Evidently no one was keeping an eye on upstream archlinux rebuilds, specifically see https://lists.archlinux.org/pipermail/arch-dev-public/2019-January/029428.html

In addition to similar recent issues with libidn2 and ruby and suchlike, you will additionally need to find all parabola-specific packages which link to libreadline.so.7 and rebuild those.

eschwartz Thanks for that Input. I'll be more careful befpore responding in the future.

eschwartz wrote:

In addition to similar recent issues with libidn2 and ruby and suchlike, you will additionally need to find all parabola-specific packages which link to libreadline.so.7 and rebuild those.

Thanks. I got a bit lost: is this comment meant for me? does this mean that installing them from the repo (pacman -S <package>) is not the solution, but building and installing them locally (makepkg; pacman -U *.pkg.tar.xz)? If building locally is required, how do I find all the packages that I would need?

nona -

no, that was saying all parabola packages with those dependencies need to be rebuilt

fdisk comes from arch core - that package is not broken - the one that needs rebuilding is the one in [nonsystemd]

unfortunately it is not possible to build this package because of one of those pesky systemd/udev conflicts that only lukeshu and megver understand - it appears that #2026 just became a high-priority issue

with [nonsystemd] repo disabled:

$ sudo libremakepkg
....
 |   > resolving dependencies...
 |   > looking for conflicting packages...
 |   > :: eudev and systemd-udev are in conflict (udev). Remove systemd-udev? [y/N] error: unresolvable package conflicts detected
 |   > error: failed to prepare transaction (conflicting dependencies)
 |   > 
 |   > :: eudev and systemd-udev are in conflict

with [nonsystemd] repo enabled:

$ sudo libremakepkg
....
 |   > resolving dependencies...
 |   > looking for conflicting packages...
 |   > :: eudev-libudev and systemd-libudev are in conflict (libudev). Remove systemd-libudev? [y/N] error: unresolvable package conflicts detected
 |   > error: failed to prepare transaction (conflicting dependencies)
 |   > 
 |   > :: eudev-libudev and systemd-libudev are in conflict

and trying to build the package outside the chroot looks like a very bad idea:

$ makepkg -s
==> Making package: util-linux 2.33.1-2.nonsystemd1 (Sun 27 Jan 2019 03:19:23 AM EST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...
resolving dependencies...
looking for conflicting packages...
:: eudev and systemd-udev are in conflict (udev). Remove systemd-udev? [y/N] y
:: eudev-libudev and systemd-libudev are in conflict (libudev). Remove systemd-libudev? [y/N]

i also tried deleting and re-creating the chroot root replica fresh

maybe this package needs to be built on an openrc system ?

but how do you do it megver? - does this package needs to be built on an openrc system ? - did i do something wrong, or does this package always require special treatment?

after the past month of lukeshu and ovruni being absent, it has become very noticeable how much of the system and tooling that only a few devs understand, and how many unknowns there would be for the others to learn in case of an emergency

in this case, if it is known that this package can never be built in the standard way, there should be comments in the PKGBUILD explaining what to do

bill-auger wrote:

but how do you do it megver? - does this package needs to be built on an openrc system ? - did i do something wrong, or does this package always require special treatment?

The chroot must be fully free from systemd (not necessarily OpenRC, unless you want to build OpenRC pkgs). That is why it is better to have a nonsystemd-chroot to build non-systemd stuff.

after the past month of lukeshu and ovruni being absent, it has become very noticeable how much of the system and tooling that only a few devs understand, and how many unknowns there would be for the others to learn in case of an emergency

in this case, if it is known that this package can never be built in the standard way, there should be comments in the PKGBUILD explaining what to do

True. Could you write about in the mailing list? (btw, I think oaken-source does already)

Megver83 wrote:

bill-auger wrote:

does this package needs to be built on an openrc system?

The chroot must be fully free from systemd (not necessarily OpenRC,

er confusion? - openrc is only one other init - yes? - so "fully free from systemd" implies "necessarily OpenRC" - doesnt it?

i think you were saying that if parabola had a third init, that could be used also - i assume that it is the purpose of the [nonsystemd] repo, to support multiple inits, whatever they may be; though today there is only one alternative to systemd

so today, this package does necessarily need to be built on an openrc system, because that is the only way today to boot parabola "fully free from systemd" - is that correct? - or maybe it is not important because the chroot does not need to boot nor start any services?

Megver83 wrote:

Could you write about in the mailing list? (btw, I think oaken-source does already)

why are you asking me to write to the mailing list, couldnt you do that? - i dont really understand what you are asking me to write about

write about what? - whether there should be a new nonsystemd librechroot; or whether unconventional build procedures should be documented?

what does oaken-source do already? - does he build in a special chroot; or does he document unconventional build procedures?

there is an open bug ticket about modifying the i686 librechroot becuase many packages will not build without the [build-support] repo enabled - if the discussion is about a new nonsystemd librechroot, maybe we could just re-use that ticket for both https://labs.parabola.nu/issues/2140

do you think it would be better to have such discussions only on the mailing list and not on redmine? - i dont know whats more effective - i have never found it easy to get more than two parabola devs in on the same conversation

bill-auger wrote:

Megver83 wrote:

bill-auger wrote:

does this package needs to be built on an openrc system?

The chroot must be fully free from systemd (not necessarily OpenRC,

er confusion? - openrc is only one other init - yes? - so "fully free from systemd" implies "necessarily OpenRC" - doesnt it?

i think you were saying that if parabola had a third init, that could be used also - i assume that it is the purpose of the [nonsystemd] repo, to support multiple inits, whatever they may be; though today there is only one alternative to systemd

so today, this package does necessarily need to be built on an openrc system, because that is the only way today to boot parabola "fully free from systemd" - is that correct? - or maybe it is not important because the chroot does not need to boot nor start any services?

We have a total of four inits:

- systemd
- openrc
- sysvinit
- runit