I installed FreeBSD 11.1 + xorg-server + xorg-apps + firefox and several other packages. Everything via 'pkg'. List of packages: https://pastebin.com/NJ8aQ5a2 I run dwm + sterm. From it, I start Firefox. Below is what I get. Note: when I did pretty much same steps in OpenBSD, it all just worked without any seg-faults. process 1331: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory See the manual page for dbus-uuidgen to correct this issue. D-Bus not built with -rdynamic so unable to print a backtrace Redirecting call to abort() to mozalloc_abort Segmentation fault (core dumped)
Over to devel/dbus maintainers. This is a problem with how D-Bus is packaged on FreeBSD and not a Firefox specific problem. On OpenBSD the dbus package will run `dbus-uuidgen --ensure` to generate the machine-id file when it's installed so that D-Bus can work correctly out of the box. On FreeBSD the rc script takes care of it and you're expected to put dbus_enable=YES into /etc/rc.conf and start D-Bus once to generate the machine-id. This is a common support problem (nightmare?) on the FreeBSD forums too [1]. Often seen when users try to install and run Xfce without having `dbus_enable=YES` in `/etc/rc.conf`. There would be IMHO no real downsides in putting @postexec %%PREFIX%%/bin/dbus-uuidgen --ensure into devel/dbus' pkg-plist on FreeBSD like on OpenBSD. [1] https://www.google.com/search?q=site%3Aforums.freebsd.org+dbus-uuidgen
(In reply to Tobias Kortkamp from comment #1) The reason that hasn't happened is because you cannot delete that file on uninstall and if you don't delete it the package builders report it as a leftover.
(In reply to Tijl Coosemans from comment #2) > The reason that hasn't happened is because you cannot delete that file > on uninstall and if you don't delete it the package builders report it > as a leftover. But packages are not being built with the leftovers check on. It's just a warning that could be ignored if there's a will and a reason to do so.
The command was removed from pkg-install in ports r347320. A possible solution would be to create a "pkg purge" command that completely deletes a package, and allow "pkg delete" to leave files like this (and configuration files) behind. The current solution in dbus doesn't trigger the leftover checks but technically the file is still a leftover.
> The command was removed from pkg-install in ports r347320. > A possible solution would be to create a "pkg purge" command that > completely deletes a package, and allow "pkg delete" to leave files like > this (and configuration files) behind. The current solution in dbus > doesn't trigger the leftover checks but technically the file is still a > leftover. Every port that has an @sample annotation in their plist leaves files behind. Poudriere doesn't care about those and pkg will print a message on package deinstall for them. You may need to manually remove ${target_file} if it is no longer needed. devel/dbus could also give the same suggestion for /var/lib/dbus/machine-id. Furthermore Mk/Scripts/check_leftovers.sh could be amended to ignore it too. It already ignores files from fontconfig, gconf, glib, ghc, etc. so there are precedents for this already.
@sample still deletes the files if they are unmodified, so it doesn't trigger poudriere checks. If you want to pursue this further you'll have to talk to portmgr I think.
(In reply to Tijl Coosemans from comment #6) Here is a review for this. Could use approval from someone from GNOME too.
Is /var/lib where it's supposed to be? I put my file into /etc/machine-id to make it work. Isn't this file something that would not change ever on the machine? Shouldn't this just be created at OS installation time in /etc/machine-id? That, IMO, would be the correct fix that could solve your pkg install/uninstall problem. It appears like dbus is a hard requirement for X11 nowadays. I think during xorg-server installation, the dbus_enable="YES" should be placed in /etc/rc.conf or there should be some other forceable mechanism where user MUST enable it to get xorg-server installed. Otherwise it looks very broken.
(In reply to Wojciech A. Koszek from comment #8) /var/lib/dbus is the default location for dbus and it works with devel/linux-c6-dbus-libs. I believe the /etc location was introduced by systemd and support for it was added in later versions of dbus. Another problem with /etc is that it may be read-only and the rc.d script needs a writable directory to put the file in.
With the maintainer hat on, the comment of tijl@ in comment #2 is correct. If portmgr@ approves the ignoring of the dbus machine-id file, then I have no problem with the proposed fix for dbus as in the review linked in comment #7.
I've abandoned the review for being open for too long with no response. If someone else still cares please take it over.
Return the PR back to the pool. I am not sure how this should be solved properly. It feels like the most elegant way would be to remind users to start dbus before starting firefox in pkg-message. Otherwise, if we decide to create the machine-id file during installation, we end up in a situation where, e.g., a VM image with preinstalled packages would have a hardcoded machine-id. Which in turn creates even more edge cases.
I've spoken to bapt and I think that we are almost ready to commit the patch from Phabricator. See Phabricator for details.