BZ#2273529 Package exclusions don't work in bootstrap phase for image builds

What's the easiest way to temporarily run the tests with some extra verbosity? eg., with bats --print-output-on-failure --verbose-run ....

Anyway, positive karma from me because things are headed in the right direction. I am hoping there's no actual problem lurking here.


The only Toolbx test that's failing is:

not ok 203 network: DNS inside Arch Linux
# (from function `assert_line' in file ./libs/bats-assert/src/assert.bash, line 488,
#  in test file ./203-network.bats, line 268)
#   `assert_line --index 0 "$ipv4_addr"' failed
# ~ /usr/share/toolbox/test/system
# -- line differs --
# index    : 0
# expected :
# actual   :
# --

Oops, I forgot that Bodhi doesn't seem to handle quoting with >.

Filed a pull request:

I suspect that the tests didn't run against toolbox-

... which has these fixes:

For example, see the failure for the 110 run: Smoke test with true(1) test. It's the same thing that I was trying to fix.

Yeah, I have been debugging it with lsm5 and santiago.

Oops! I didn't expect python3-dnf to contain %{_bindir}/dnf-3 and %{_bindir}/dnf4. That's definitely a big problem for Fedora Silverblue.

Secondly, it looks like disabling subscription-manager's DNF plugin on Fedora hosts prevents it from upgrading UBI containers to RHEL.

Anyway, ending up with DNF executables on Silverblue is definitely a big problem. I will submit another build to drop the weak dependency on subscription-manager.

Thanks Alex - apology accepted. No hard feelings.

This update literally got hosed (Bodhi called it obsolete) with the toolbox- build losing all its tags when the third negative karma came in. I had to do jump through various hoops to undo all that. That's not fun when right before the holidays.

When I restored it, I made sure to bump the negative karma threshold really high to 50 to avoid this. That's why you see the 47 figure.

I think what I will do in the new year is to flip the defaults of DNF's subscription-manager plugin to have it disabled by default unless there's some real problem with doing that.

Zeno, so why have you not participated there on the subscription-manager issue? Or are you waiting to attack the next package that happens to rely on subscription-manager.

You are a spammer who is spamming this update, and you literally borked it without adding anything new to the discussion. Then you topped it up with a bunch of snarky and aggressive comments. You are mistaken if you think that I won't call you out on that.

The link to that subscription-manager issue is the first useful information that you shared.

By the way, you can disable the DNF plugin shipped by subscription-manager by editing /etc/dnf/plugins/subscription-manager.conf.

Now you can say that it could be advertised or documented better, but it's not exactly hidden either. It's pretty easy to spot if you do a ls --recursive /etc/dnf.

Zeno, you are coming across as a spammer here.

So far, you have contributed nothing other than a couple of passive aggressive comments. If you were genuine in your desire to improve Fedora, then you could have submitted a subscription-manager issue to streamline their output. Have you done that?

Alex, when you hose a pending update with a deluge of negative karma, then it implies that something is very seriously wrong with the update. Arguing about three extra lines in your DNF output is nowhere close to that.

You are essentially saying that nobody can depend on Fedora's subscription-manager package, at least not any package that's sufficiently popular. At that point, we might as well force the removal of subscription-manager from Fedora.

If you want to improve the subscription-manager user interface, then that's fine. I can think of several improvements to it. However, it's quite absurd to hold a toolbox update hostage over deficiencies in the subscription-manager UI.

Those extra three lines are nowhere close to being considered serious breakage. Are they causing data loss? Are they preventing machines from booting and updating? DNF generates dozens if not hundreds of lines, and it's output has changed and swollen over the years. Lots of terminal programs lead to lots of spew. Take any build system for example.

While we haggle over this, there are several users who really want to be able to access a RHEL user space environment on Fedora - either for upstream maintenance or Fedora EPEL work or RHEL work. To do that they need a way to update their UBI Toolbx containers to RHEL.

Before you again use the word spam, consider this:

  • You are doing a disservice to your role as a tester by actually trying to force me to ship sub-optimal software.

  • Would you throw such a fit if Autoconf generated a configure script had a few extra lines of spew?

  • You are trying to block something that the Fedora Workstation Working Group wants to achieve.

  • You are doing this in an insidious way by taking advantage of the fact that a lot of people are already on their way out for the holidays.

Looks like Bodhi doesn't support quoting. :(

Second, wasn't this planned for F40, as per the ticket you linked to?

My original intent was to add it to fedora-comps for Fedora Rawhide/40 and advertise it as a Fedora Workstation feature. The discussion in the Fedora Workstation Working Group ticket felt that it's better to leave it as a toolbox package-level feature and dependency.

In fact there were suggestions to add it to even other packages like podman, systemd-container, mkosi, etc., and, even, the hypothetical case of SUSEConnect was discussed.

As the owner of the toolbox package, I do want to have the dependency in existing stable Fedoras too, because it significantly enhances the usability of Toolbx with RHEL containers. In contrast, fedora-comps is used during OS installation. There's no sense in adding to existing stable Fedoras because their installation media are not going to be regenerated. Hence, Fedora Rawhide/40 is the only option for fedora-comps.

It's a weak dependency. So, you are free to remove it if you want to.

Until it gets updated, and the weak dependencies are installed again.

Nobody is forcing you to have toolbox on your system either.

Fedora CoreOS is a genuine case that doesn't want to have subscription-manager and that's already taken care of.

I don't understand why you insist on calling three extra lines in your DNF output as spam. DNF isn't a particularly terse command, and I find it odd to use the word spam in this context.

Will you still call it spam when it shows up in Fedora 40?

It's a weak dependency. So, you are free to remove it if you want to. It's assumed that those using the command line with strong opinions on such things will be able to do that.

It's not spam. It's intentional and as desired by the Fedora Workstation Working Group: