firewalld seems to be at the top of a chain with libX11 at the bottom: firewalld -> pygobject3 -> pycairo -> cairo -> mesa-libGL + mesa-libEGL -> libX(various) -> libX11 . also pulled in at various levels of that chain: fontconfig and fontpackages-filesystem (cairo), gobject-instrospection (pygobject3), libpng (cairo), libwayland-{server,client} (mesa-libEGL), mesa-libgbm and mesa-libglapi (mesa-libEGL), pixman (cairo), 

another firewalld chain pulls in dbus-python, libselinux-python, python-decorator, python-slip and python-slip-dbus: firewalld -> python-slip-dbus -> the rest. it also pulls in pygobject2 via python-slip-dbus: so firewalld somehow manages to depend on pygobject2 and pygobject3...

device-mapper comes in via lvm.

ebtables comes in directly from firewalld.

groff, groff-base and less is a chain, that was pretty much just left out of Alpha, I agree less ought to be in minimal.

libmicrohttpd, libtasn1, p11-kit and qrencode-libs come in via systemd, that was discussed on devel@ I think.

libpipeline comes in via man-db, which looks like another sensible addition.

So it looks like firewalld is definitely our big culprit here. It would be nice if those deps can be pruned.

Re-assigning to firewalld as that's the big offender here, the other changes are pretty much legit.

(In reply to comment #1)
> firewalld seems to be at the top of a chain with libX11 at the bottom:
> firewalld -> pygobject3 -> pycairo
See also bug #855346

fwiw groff in addition to groff-base is a packaging error in less and should be fixed -- see bug #868376. If that fix is included and you're still seeing this, we should track down whatever else is causing it.

matthew: that update is still in updates-testing so it wouldn't be in TC7.

thanks miloslav, didn't catch that one. this is kind of a superset of that one, so I'll set it to depend on that one.

> libmicrohttpd, libtasn1, p11-kit and qrencode-libs come in via systemd, that
> was discussed on devel@ I think.

Yes, Lennart said it was easy to split it out into a sub package. It seems he hasn't. I would really like to see this done

(In reply to comment #7)
> > libmicrohttpd, libtasn1, p11-kit and qrencode-libs come in via systemd, that
> > was discussed on devel@ I think.
> 
> Yes, Lennart said it was easy to split it out into a sub package. It seems
> he hasn't. I would really like to see this done

Is there a bug number for that request?

I'm not sure it will be possible to break the firewalld / pygobject3 (or the firewalld / dbus-python) dep chain. The server.py code (core of the firewalld daemon) runs:

        dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
        bus = dbus.SystemBus()
        name = dbus.service.BusName(DBUS_INTERFACE, bus=bus)
        service = FirewallD(name, DBUS_PATH)

        mainloop = GObject.MainLoop()
        slip.dbus.service.set_mainloop(mainloop)
        mainloop.run()

Short of rewriting firewalld to not use dbus or gobject, I don't think there is any possible pruning here. Maybe we should move firewalld out of the minimal install and only pull it on GNOME?

(In reply to comment #9)
> 
> Short of rewriting firewalld to not use dbus or gobject,

These two are already in minimal (right?); it's pygobject acting as the bridge.  See the dependent bug:

https://bugzilla.redhat.com/show_bug.cgi?id=855346

I will talk to Nils. Maybe we could get a python-slip-dbus version which does not require pygobject2.

firewalld has been pushed into base in the first place. As it is now in minimal set after the rework of the package groups, it might be good to work on #855346. 

Would it be enough to get the requirements of pycairo and cairo (and all dependant packages) out of the base pygobject3 package to have an acceptable minimal package set?

The list would reduce to (removed all packages, that are not needed by firewalld):

+dbus-python
+ebtables
+firewalld
+gobject-introspection
+libselinux-python              (needed by python-slip)
+pygobject3
+python-decorator
+python-slip
+python-slip-dbus

Maybe it is also possible to get rid of libselinux-python.

(In reply to comment #13)
> The list would reduce to (removed all packages, that are not needed by
> firewalld):
> 
> +dbus-python
> +ebtables
> +firewalld
> +gobject-introspection
> +libselinux-python              (needed by python-slip)
> +pygobject3
> +python-decorator
> +python-slip
> +python-slip-dbus
> 
> Maybe it is also possible to get rid of libselinux-python.

I think we can live with this. It's growing minimal by a little bit, but none of these packages are huge.

I find it sad to see yet more Python stuff added to the default install. (Why was firewalld implemented in Python? :-( For a systemwide always-running daemon, the memory use penalty really sucks!) I'd have loved Python being eventually kicked out of the default install instead (with yum getting replaced by zif), we're now doing the opposite. :-(

Oops, s/default/minimal/ (and Python is most definitely NOT minimal).

(In reply to comment #14)
> (In reply to comment #13)
> > The list would reduce to (removed all packages, that are not needed by
> > firewalld):
> > 
> > +dbus-python
> > +ebtables
> > +firewalld
> > +gobject-introspection
> > +libselinux-python              (needed by python-slip)
> > +pygobject3
> > +python-decorator
> > +python-slip
> > +python-slip-dbus
> > 
> > Maybe it is also possible to get rid of libselinux-python.
> 
> I think we can live with this. It's growing minimal by a little bit, but
> none of these packages are huge.

Yes, that is an acceptable raise of the minimal package set.

(In reply to comment #15)
> I find it sad to see yet more Python stuff added to the default install.
> (Why was firewalld implemented in Python? :-( For a systemwide
> always-running daemon, the memory use penalty really sucks!) I'd have loved
> Python being eventually kicked out of the default install instead (with yum
> getting replaced by zif), we're now doing the opposite. :-(

Without commenting one way or another: this is out of scope for this bug and should be addressed elsewhere.

(In reply to comment #9)
> I'm not sure it will be possible to break the firewalld / pygobject3 (or the
> firewalld / dbus-python) dep chain. The server.py code (core of the
> firewalld daemon) runs:
> 
>         dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
>         bus = dbus.SystemBus()
>         name = dbus.service.BusName(DBUS_INTERFACE, bus=bus)
>         service = FirewallD(name, DBUS_PATH)
> 
>         mainloop = GObject.MainLoop()
>         slip.dbus.service.set_mainloop(mainloop)
>         mainloop.run()
> 
> Short of rewriting firewalld to not use dbus or gobject, I don't think there
> is any possible pruning here. Maybe we should move firewalld out of the
> minimal install and only pull it on GNOME?

If the package already requires pygobject2 (python-slip)

Why not use that and loose the pygobject3 requirement

import dbus
import dbus.mainloop.glib
import slip.dbus
import gobject


def main():
    dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
    bus = dbus.SystemBus()
    name = dbus.service.BusName(DBUS_INTERFACE, bus=bus)
    service = FirewallD(name, DBUS_PATH)

    mainloop = gobject.MainLoop()
    slip.dbus.service.set_mainloop(mainloop)
    mainloop.run()

firewalld is using GLib, GObject and Gio from pygobject3.

Using pygobject2 glib instead of pygobject3 GLib results in warnings in the mainloop mostly in combination with D-BUS or gio:
  "Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed"

The UI part is using more parts from pygobject3: Gtk, Notify and NetworkManager. The use of glib, gobject and gio from pygobject2 is not possible without lots of warnings like the above.

I've built python-slip-0.2.22-1.fc18 which is able to work with both (classic) pygobject2/gobject and "new" pygobject3/gi.repository.GObject, it'll default to using the latter if the user doesn't import the legacy gobject module first. I'll let Thomas roll an update which includes this version.

I've built python-slip-0.2.23-1.fc18 now because 0.2.22 didn't distribute the new files needed for this to work. I've also changed the default to classic gobject if neither is imported already and both are available, so as not to break other users of the slip.dbus module.

python-slip-0.2.23-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/python-slip-0.2.23-1.fc18

Moving back to assigned, as this is only part of the fix.

You'll need to edit the update so it isn't marked as fixing this bug, or else Bodhi will keep poking this bug back to MODIFIED / ON_QA whenever the update gets pushed anywhere.

Unchecking the "close bugs when update goes stable" checkbox should be sufficient.

"close bugs when update goes stable" is unchecked.

It is unchecked since I created the update.

Resetting into assigned state.

> "close bugs when update goes stable" is unchecked.

Then everything should be fine.

The python-slip-0.2.24 update should make firewalld (and other users) fall back to checking UIDs if polkit is not available. In this case, only the root user (UID 0) is permitted to execute methods that are decorated as needing authorization for a specific action, other UIDs are denied. Methods not decorated in this fashion can still be executed by any UID.

With this update, programs using slip.dbus, slip.dbus.polkit instead of accessing polkit directly (e.g. firewalld) shouldn't have a hard dependency on polkit anymore.

Any update here? I'm still getting firewalld pulling the following into my otherwise minimal image:

cairo
dbus-glib
dbus-python
ebtables
fontconfig
fontpackages-filesystem
gobject-introspection
js
libdrm
libpciaccess
libpng
libselinux-python
libwayland-client
libwayland-server
libX11
libX11-common
libXau
libxcb
libXdamage
libXext
libXfixes
libXrender
libXxf86vm
mesa-libEGL
mesa-libgbm
mesa-libGL
mesa-libglapi
pixman
polkit
pycairo
pygobject2
pygobject3
python-decorator
python-slip
python-slip-dbus

(In reply to comment #32)
> Any update here? I'm still getting firewalld pulling the following into my
> otherwise minimal image:
> 
[...]
> js
[...]
> polkit
[...]

Which version of firewalld and python-slip do you have? On an up to date F18 VM which had firewalld-0.2.11-1.fc18 and python-slip{,-dbus}-0.2.24-1.fc18 installed, I attempted to remove js and polkit and both would remove a ton of other packages because of dependencies, but not firewalld.

(In reply to comment #33)
> Which version of firewalld and python-slip do you have? On an up to date F18
> VM which had firewalld-0.2.11-1.fc18 and python-slip{,-dbus}-0.2.24-1.fc18
> installed, I attempted to remove js and polkit and both would remove a ton
> of other packages because of dependencies, but not firewalld.

The issue is the other way around. firewalld is a leaf, but pulls in a forest of other packages.

pygobject3-3.4.2-4.fc18,firewalld-0.2.11-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/pygobject3-3.4.2-4.fc18,firewalld-0.2.11-2.fc18

Proposing as NTH for F18 final. Obviously reducing the size of minimal install is a worthy goal, and equally obviously we can't do it post-release for DVD installs.

Package pygobject3-3.4.2-4.fc18, firewalld-0.2.11-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing pygobject3-3.4.2-4.fc18 firewalld-0.2.11-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20311/pygobject3-3.4.2-4.fc18,firewalld-0.2.11-2.fc18
then log in and leave karma (feedback).

(In reply to comment #34)
> The issue is the other way around. firewalld is a leaf, but pulls in a
> forest of other packages.

If firewalld really pulled in these packages I tried, removing them would remove firewalld as well, wouldn't it?

They're probably pulled in as an script requirement of something. Not sure what.

With current updates testing, diff from before to with firewalld is:

dbus-glib
dbus-python
ebtables
firewalld
gobject-introspection
libselinux-python
pygobject3-base
pyliblzma
python-decorator
python-slip
python-slip-dbus


which is much more sane. Thanks everyone!

> Obviously reducing the size of minimal install is a worthy goal, and equally
> obviously we can't do it post-release for DVD installs.

Nor for Live installs, for that matter. DVD installs can be done with updates, at least, Live installs are stuck with what was there at GA time, the dependency resolution isn't even done by the user in the Live case.

Discussed at 2012-12-17 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . Accepted as NTH as reducing the dep load of firewalld is important to minimal install and some spins, and obviously cannot be done post-release.

sgallagh, can you edit https://admin.fedoraproject.org/updates/pygobject3-3.4.2-4.fc18,firewalld-0.2.11-2.fc18 and mark it as fixing this bug?

I just tested and doing a current net install *this* issue seems to be fixed, but going by the package count, something else has shown up - I don't see cairo or libX11 or anything, but package count is still over 230. I'll try and figure out what else broke.

pygobject3-3.4.2-4.fc18, firewalld-0.2.11-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

python-slip-0.2.24-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.