search

eudev-project / eudev

Repository for eudev development
GNU General Public License v2.0
529 stars 144 forks source link

libgudev requires libudev >= 251, but eudev just provides version 243 #249

Closed reliant8307 closed 1 year ago

reliant8307 commented 1 year ago

Since libgudev requires libudev >= 251, but eudev just provides version 243, is there any plans to upgrade eudev to at least version 251? I mean, the version returned by:

$ pkg-config --modversion libudev
243

Thanks!

nekopsykose commented 1 year ago

packaging-wise, it's trivial to just patch such a check (in the meson.build dependency for libudev, inside libgudev's build; i've had to do that multiple times when things declare some high version but don't actually need it at all).

however, it's not actually that trivial in this case, because the actual function they bumped for is missing: 

../gudev/gudevdevice.c:146:12: error: implicit declaration of function 'udev_device_get_current_tags_list_entry'; did you mean 'udev_device_get_tags_list_entr'? [-Werror=implicit-function-declaration]
  146 |   for (l = udev_device_get_current_tags_list_entry (device->priv->udevice); l != NULL; l = udev_list_entry_get_next (l))
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

this was added in https://github.com/systemd/systemd/commit/3b684be04b95bd5264dff0f2af343c52b4dba86b, so 247 was the first version with it. there's no further requirements in this case..

i don't know how easy it would be to implement this one function.

fungilife commented 1 year ago

Trying to fool it is 251 by adding a version tag in packaging still didn't work. But even building with an extracted libudev from systemd's udev and succesfully building libgudev, builds like upower still find the discrepancy if you are running the build based on libeudev

So it is either holding back to previous libgudev and its dependents or have to move to a libudev based on systemd's udev.

Dependents are such as: udisks2 umockdev colord libwacom upower and then secondary dependents to those leads to a distribution falling apart or remain stagnant.

milkylainen commented 1 year ago

I don't know the use cases here, but you can always roll back the sticky tags commits from libgudev. Then again, what would be the point of upgrading libgudev? iiuc, it's just one code functional commit beside the sticky tags that encompass the 237->238.

thesamesam commented 1 year ago

The upstream change in libgudev is https://gitlab.gnome.org/GNOME/libgudev/-/commit/0cfd33f0c1101b4a93c503cbda4274786a6d41e2.

anticapitalista commented 1 year ago

Debian sid now has libgudev 238 and this breaks keyboard and mouse on antiX-sid. We use eudev not udev since antiX is free from both systemd and elogind.

masterovhell commented 1 year ago

Can confirm, Devuan user and I woke up to keyboard and mouse not working, rolled back through timeshift.

masterovhell commented 1 year ago

is there a roadmap of when this might get fixed?

ncopa commented 1 year ago

This will require some effort. Not much has been ported since 2015 so it is probably less work to create a new fork at this point.

That said, a stupid (broken) workaround might be relatively easy to do.

bbonev commented 1 year ago

There is no need to port everything, just the new API and its dependencies.

I am traveling and the best I can do now is to review/merge a PR (in case some fine folks make one).

I have no idea about the scope of the change - it may be very small or really huge...

Arnvidr commented 1 year ago

Would a dummy implementation lead to trouble? What I mean is implementing udev_device_get_current_tags_list_entry() as simply calling udev_device_get_tags_list_entry()

_public_ struct udev_list_entry *udev_device_get_current_tags_list_entry(struct udev_device *udev_device) {
    return udev_device_get_tags_list_entry(udev_device);
}

The other added function, udev_device_has_current_tag() seems to just call a different function that already exists, but does not exist in eudev. Maybe that could simply be skipped.

csillag commented 1 year ago

Another Devuan user here, hit by the same issue. It would be great to have some solution relatively soon. As it stands now, cinnamon is broken but I can still use metacity, but I wouldn't dare to reboot my main production workstation, because I am not sure X would come boot up ever again.

bbonev commented 1 year ago

Nice observation @Arnvidr!

Looks like the current eudev device database does not implement the concept of "current" tags. OTOH systemd's code has a check if that concept is implemented in the device database, and in case it is not, falls back to returning all tags as current.

Implementing this through the fall-back path as a quick'n'dirty fix - this will break stuff that relies on the difference between current and non-current tags. The proper fix needs adding the current tag concept to the device database and returning the appropriate flags only.

About fixing running systems, the proper way is to downgrade libgudev to the previous version and pin it there. That will still allow other updates and avoid that breakage.

It will take some time for #253 to get peer reviewed, modified and eventually approved, more time for a release and even more for it to reach your distribution.

masterovhell commented 1 year ago

Another Devuan user here, hit by the same issue. It would be great to have some solution relatively soon. As it stands now, cinnamon is broken but I can still use metacity, but I wouldn't dare to reboot my main production workstation, because I am not sure X would come boot up ever again.

Yeah at this point I just completely reinstalled on Devuan Stable, got everything up and running again. I'm not even going to try and go back to testing with any other possible hijinks IBM tries.

fungilife commented 1 year ago

The problem is more pervasive than what Debian feeds into devuan unmaintained testing and sid repositories. Many issues are upstream and not distro related.

Take a project like util-linux, not too long ago autonomized by kernel.org into its own, although requiring to find libudev.so present to build, once systemd is disabled it pretends as libudev doesn't exist for the build. Thinking of how many critical utilities for filesystem management go through this, it becomes an uneasy feeling to wonder what utilities are missed by lack of libudev. (it is either systemd udev or none)

I don't know how others weigh the decision to continue util-linux development without the linux/kernel.org signature, let us keep faith that the kernel is not a systemd only kernel for a while longer, maybe December 2026 when all LTS deadlines expire.

eylles commented 1 year ago

Looks like the current eudev device database does not implement the concept of "current" tags. OTOH systemd's code has a check if that concept is implemented in the device database, and in case it is not, falls back to returning all tags as current.

Implementing this through the fall-back path as a quick'n'dirty fix - this will break stuff that relies on the difference between current and non-current tags. The proper fix needs adding the current tag concept to the device database and returning the appropriate flags only.

well after some quick testing one of the facilities that break with the dirty fix is upower 1.90.2 that does require libgudev-1.0-0 >=238, tested on devuan ceres with upower 1.90.2-4 and upower fails to report change on battery percentage on my laptop (hp probook 445 g7) tho i will do some more testing to be sure.

bbonev commented 1 year ago

@eylles can you please verify that you are not hitting #254 instead?

eylles commented 1 year ago

@bbonev sorry for taking this long to provide feedback, but yes after reading on what is going on and checking that i'm running eudev 3.2.12-3 , i'm probably hitting #254 tho i have not had the time to build eudev from source, please correct me here if i'm wrong on the steps to build and install eudev "safely the deb way" for testing, what i would do is:

eeyrjmr commented 1 year ago

Eudev is planned for removal from Gentoo 2023-10-11 in part due to this bug and others

https://packages.gentoo.org/packages/sys-fs/eudev

bbonev commented 1 year ago

@eeyrjmr This is solely Gentoo's decision. Thanks for letting us know.

KenjiBrown commented 1 year ago

I have pushed eudev-3.2.12-r2.ebuild (with the stickytags patch) to without-systemd gentoo overlay https://github.com/KenjiBrown/without-systemd/blob/master/sys-fs/eudev/eudev-3.2.12-r2.ebuild After the update I have been able to compile dev-libs/libgudev-238-r1::gentoo without any other problem.