Bug 240138 - [NEW PORT] sysutils/libudisks: Library from udisks project, to access and manipulate disks, storage devices and technologies
Summary: [NEW PORT] sysutils/libudisks: Library from udisks project, to access and man...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL: https://github.com/storaged-project/u...
Keywords: feature, needs-patch
Depends on:
Blocks: 240110
  Show dependency treegraph
 
Reported: 2019-08-27 01:17 UTC by PauAmma
Modified: 2019-09-08 20:05 UTC (History)
3 users (show)

See Also:
pauamma: maintainer-feedback? (pauamma)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description PauAmma 2019-08-27 01:17:02 UTC
Since it appears that bug 240110 will require using udisks2 instead of devel/libgudev and devel/libudev-devd as I initially thought, I or someone should port it. I'm not sure udisks2 belongs in the devel/ category, but I put it there on the grounds that it's a sorta-kinda replacement for these 2 libraries.

https://www.freedesktop.org/wiki/Software/udisks/
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-08-27 02:50:24 UTC
Most ports matching disk* are in the sysutils category, so that's probably a better primary category for it. 

We try to avoid devel unless its specifically and only development related, and only then if there's not a better primary category (where devel can be secondary)
Comment 2 Gleb Popov freebsd_committer 2019-08-27 07:29:30 UTC
UDisks contains Linux-specific backed part. When considering porting it, I decided that it is easier to implement the same service for FreeBSD from scratch. This resulted in sysutils/bsdisks port. It implements minimal functionality required to mount volumes at the moment.

The libudisks part of UDisks project is a D-Bus bindings library, and should be portable.
Comment 3 Ting-Wei Lan 2019-08-27 08:48:24 UTC
(In reply to Gleb Popov from comment #2)
Has anyone asked the upstream if they are willing to accept patches to build just the client library or add FreeBSD-specific code? If the upstream accepts patches for non-Linux operating systems, I think it will be nice to have at least the client library, so we can stop converting projects using the client library to do D-Bus calls directly.

I just ran 'readelf -d /usr/libexec/udisks2/udisksd' on Linux, and I found it needs GLib. It may be a problem on FreeBSD because FreeBSD geom library is known to conflict with GLib. Both FreeBSD geom library and GLib use 'g_' prefix for their function names, which is known to cause problems for libgtop and force us to disable all code using geom in libgtop.
Comment 4 PauAmma 2019-08-27 22:34:14 UTC
(In reply to Ting-Wei Lan from comment #3)
OK, this sounds to me like you and Gleb Popov are suggesting to do the following, not necessarily in that order:

1- split off libudisks from udisks2,
2- patch it so it can use bsdisks instead,
3- offer those patches to upstream for their consideration.

If my understanding is correct, who's in charge of drafting an email to the udisks2 upstream? Me? (I don't want to tread on anyone's toes, but I don't want this bug to sit around gathering dust if no one else has time to move on it.)
Comment 5 PauAmma 2019-08-27 22:36:48 UTC
(In reply to Kubilay Kocak from comment #1)
Is the "maintainer feedback" flag asking me to agree with the change from devel/ to sysutils/ ? If so, how do I say I agree (which I do)? Change it to + ?
Comment 6 Gleb Popov freebsd_committer 2019-08-28 07:07:05 UTC
(In reply to PauAmma from comment #4)
You shouldn't need p.2 at all and regarding ps. 1 and 3, I'd recommend you do the following:

- name the port sysutils/libudisks
- use UDisks2 distfile
- patch configure script to pass on FreeBSD (it looks for udev, which is not applicable for us)
- build only libudisks target and install its products

In ideal case, this shouldn't even require communicating with upstream.

I'd do this myself, but I'm away from computer ATM.
Comment 7 Ting-Wei Lan 2019-08-29 08:14:55 UTC
(In reply to Gleb Popov from comment #6)
It is not required, but it is usually better to let the upstream know that there are people interested in building only the client library. Ideally, all required patches will be merged upstream and no patch will be required in the port.
Comment 8 Ting-Wei Lan 2019-09-08 04:23:37 UTC
I just submitted a pull request to upstream to allow building without the Linux-only udisks daemon: https://github.com/storaged-project/udisks/pull/693. It can be built by passing --disable-daemon --disable-gtk-doc to configure, but there are a few warnings when using the client library with bsdisks.

(process:23042): GLib-GIO-WARNING **: 12:21:10.961: Trying to set property Configuration of type aa{sv} but according to the expected interface the type is a(sa{sv})

(process:23042): GLib-GIO-WARNING **: 12:21:10.961: Trying to set property Symlinks of type as but according to the expected interface the type is aay
Comment 9 Gleb Popov freebsd_committer 2019-09-08 10:03:03 UTC
(In reply to Ting-Wei Lan from comment #8)

Great news!

> there are a few warnings when using the client library with bsdisks.

Should be fixed in bsdisks HEAD revision. Please try it out.
Comment 10 Ting-Wei Lan 2019-09-08 10:23:06 UTC
(In reply to Gleb Popov from comment #9)
The warning for Symlinks is now resolved, but Configuration still shows warnings.

(gnome-control-center:64166): GLib-GIO-WARNING **: 18:22:04.156: Trying to set property Configuration of type (sa{sv}) but according to the expected interface the type is a{sv}
Comment 11 Gleb Popov freebsd_committer 2019-09-08 10:39:27 UTC
(In reply to Ting-Wei Lan from comment #10)
Should be fixed too now. Thanks for testing.
Comment 12 Ting-Wei Lan 2019-09-08 11:35:35 UTC
(In reply to Gleb Popov from comment #11)
Yes, it is fixed. There is no warning now.
Comment 13 PauAmma 2019-09-08 13:22:37 UTC
(In reply to Ting-Wei Lan from comment #8)
Wow! You're way faster that me. Thanks. *goes look at PR to see what needed to be done*